Redis 相比memcached 有哪些優(yōu)勢?

(1)memcached所有的值均是簡單的字符串，redis 作為其替代者，支持更為豐富的數(shù)據(jù)類型

(2)redis 的速度比 memcached 快很多

(3)redis 可以持久化其數(shù)據(jù)

Redis 支持哪幾種數(shù)據(jù)類型?

String ListSetSorted Set hashes

Redis 集群方案應(yīng)該怎么做?都有哪些方案?

1.twemproxy，大概概念是，它類似于一個代理方式，使用方法和普通 redis 無任何區(qū)別，設(shè)置好它下屬的多個 redis 實例后，使用時在本需要連接 redis 的地方改為連接 twemproxy，它會以一個代理的身份接收請求并使用一致性 hash 算法,將請求轉(zhuǎn)接到具體redis,將結(jié)果再返回 twemproxy。使用方式簡便(相對 redis只需修改連接端口)，對舊項目擴(kuò)展的首選。 問題: twemproxy 自身單端口實例的壓力，使用一致性 hash 后，對 redis 節(jié)點數(shù)量改變時候的計算值的改變，數(shù)據(jù)無法自動移動到新的節(jié)點。

分布式有哪些理論?

CAP、BASE。分布式 CAP 理論，任何一個分布式系統(tǒng)都無法同時滿足 Consistency(一致性)、Availability(可用性)、Partitiontolerance(分區(qū)容錯性)這三個基本需求。最多只能滿足其中兩項。而 Partition tolerance(分區(qū)容錯性)是必須的，因此一般是 CP，或者AP。

你怎么理解分布式一致性?

數(shù)據(jù)一致性通常指關(guān)聯(lián)數(shù)據(jù)之間的邏輯關(guān)系是否正確和完整。在分布式系統(tǒng)中，數(shù)據(jù)一致性往往指的是由于數(shù)據(jù)的復(fù)制，不同數(shù)據(jù)節(jié)點中的數(shù)據(jù)內(nèi)容是否完整并且相同。

一致性還分為強一致性，弱一致性，還有最終一致性。強一致性就是馬上就保持一致。

最終一致性是指經(jīng)過一段時間后，可以保持一致。

你怎么理解分布式事務(wù)? 分布式事務(wù)的協(xié)議有哪些?

分布式事務(wù)是指會涉及到操作多個數(shù)據(jù)庫的事務(wù)。目的是為了保證分布式系統(tǒng)中的數(shù)據(jù)一致性。分布式事務(wù)類型:二階段提交 2PC，三階段提交3PC。

2PC:第一階段: 準(zhǔn)備階段(投票階段)和第二階段: 提交階段(執(zhí)行階段)。

3PC : 三個階段: CanCommit 、PreCommit 、DoCommit。

問:分布式事務(wù)的解決方案有哪些?

分布式事務(wù)解決方案: 補償機制 TCC、XA 、消息隊列 MQ。

Dubbo的底層實現(xiàn)原理和機制

• 高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案
• SOA服務(wù)治理方案
• Dubbo缺省協(xié)議采用單一長連接和NIO異步通訊，
• 適合于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用，以及服務(wù)消費者機器數(shù)遠(yuǎn)大于服務(wù)提供者機器數(shù)的情況

描述一個服務(wù)從發(fā)布到被消費的詳細(xì)過程

首先先獲取zk的配置信息，然后獲取需要暴露的ur，然后調(diào)用registry.register方法將url注冊到zookeeper上去。

分布式系統(tǒng)怎么做服務(wù)治理

針對互聯(lián)網(wǎng)業(yè)務(wù)的特點，eg 突發(fā)的流量高峰、網(wǎng)絡(luò)延時、機房故障等，重點針對大規(guī)模跨機房的海量服務(wù)進(jìn)行運行態(tài)治理，保障線上服務(wù)的高SLA，滿足用戶的體驗，常用的策略包括限流降級、服務(wù)嵌入遷出、服務(wù)動態(tài)路由和灰度發(fā)布等

接口的冪等性的概念

暴等的意思是同一個操作，重復(fù)執(zhí)行多次，跟執(zhí)行一次結(jié)果一致。消息暴等，即消息發(fā)送操作對于消息消費來說是暴等。也就是相同的消息發(fā)送多次，跟發(fā)送一次是一樣的，這個消息只會被消費一次。

消息中間件如何解決消息丟失問題

為了解決消息丟失問題，我們引入了一些重發(fā)機制，但也帶來的另外一個問題:消息重復(fù)，我們來看下都有哪些情況會導(dǎo)致消息重復(fù):

消息發(fā)送超時，處于不確定狀態(tài)，導(dǎo)致重試發(fā)送消息，有可能之前的消息已經(jīng)發(fā)送成功，會出現(xiàn)消息重復(fù)的情況。解決的思路是，每個消息生成一個消息id，如果發(fā)送的消息Broker已經(jīng)存在了，則丟棄。這種解決辦法需要維護(hù)一個已經(jīng)接收的消息的message id list。

消息在Broker中只有一份，但是consumer重啟前，未及時更新offset，導(dǎo)致consumer重啟之后重復(fù)消費消息。

上游業(yè)務(wù)給每個message 分配一個message D，下游業(yè)務(wù)在接收到message之后，執(zhí)行業(yè)務(wù)并且保存message lD，而且要講兩部分放到同一個事務(wù)中，保證業(yè)務(wù)執(zhí)行成功，message lD肯定保存，業(yè)務(wù)執(zhí)行失敗，message lD肯定不會保存下來，利用db中存儲的message id來做暴等。我們可以重新封裝producer client和consumer client，將這部分message D分配和判重的邏輯封裝到client lib里面。

以上就是“面試官經(jīng)常被問到的分布式緩存面試題”，你能回答上來嗎?如果想要了解更多的Java面試題相關(guān)內(nèi)容，可以關(guān)注動力節(jié)點Java官網(wǎng)。