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

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

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

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

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

String ListSetSorted Set hashes

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

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

分布式有哪些理論?

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

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

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

一致性還分為強(qiáng)一致性，弱一致性，還有最終一致性。強(qiáng)一致性就是馬上就保持一致。

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

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

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

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

3PC : 三個(gè)階段: CanCommit 、PreCommit 、DoCommit。

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

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

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

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

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

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

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

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

接口的冪等性的概念

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

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

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

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

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

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

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