摘要：面試官聊下的分片集群，先聊好咯面試官是才有的官方集群方案，這塊你了解多少候選者嗯，要不還是從基礎(chǔ)講起唄候選者在前面聊的時候，提到的都是單實例存儲所有的數(shù)據(jù)。

面試官：聊下Redis的分片集群，先聊 Redis Cluster好咯？

面試官：Redis Cluser是Redis 3.x才有的官方集群方案，這塊你了解多少？

候選者：嗯，要不還是從基礎(chǔ)講起唄？

候選者：在前面聊Redis的時候，提到的Redis都是「單實例」存儲所有的數(shù)據(jù)。

候選者：1. 主從模式下實現(xiàn)讀寫分離的架構(gòu)，可以讓多個從服務(wù)器承載「讀流量」，但面對「寫流量」時，始終是只有主服務(wù)器在抗。

候選者：2. 「縱向擴(kuò)展」升級Redis服務(wù)器硬件能力，但升級至一定程度下，就不劃算了。

候選者：縱向擴(kuò)展意味著「大內(nèi)存」，Redis持久化時的"成本"會加大（Redis做RDB持久化，是全量的，fork子進(jìn)程時有可能由于使用內(nèi)存過大，導(dǎo)致主線程阻塞時間過長）

候選者：所以，「單實例」是有瓶頸的

候選者：「縱向擴(kuò)展」不行，就「橫向擴(kuò)展」唄。

候選者：用多個Redis實例來組成一個集群，按照一定的規(guī)則把數(shù)據(jù)「分發(fā)」到不同的Redis實例上。當(dāng)集群所有的Redis實例的數(shù)據(jù)加起來，那這份數(shù)據(jù)就是全的

候選者：其實就是「分布式」的概念（：只不過，在Redis里，好像叫「分片集群」的人比較多？

候選者：從前面就得知了，要「分布式存儲」，就肯定避免不了對數(shù)據(jù)進(jìn)行「分發(fā)」(也是路由的意思)

候選者：從Redis Cluster講起吧，它的「路由」是做在客戶端的（SDK已經(jīng)集成了路由轉(zhuǎn)發(fā)的功能）

候選者：Redis Cluster對數(shù)據(jù)的分發(fā)的邏輯中，涉及到「哈希槽」(Hash Solt)的概念

候選者：Redis Cluster默認(rèn)一個集群有16384個哈希槽，這些哈希槽會分配到不同的Redis實例中

候選者：至于怎么「瓜分」，可以直接均分，也可以「手動」設(shè)置每個Redis實例的哈希槽，全由我們來決定

候選者：重要的是，我們要把這16384個都得瓜分完，不能有剩余！

候選者：當(dāng)客戶端有數(shù)據(jù)進(jìn)行寫入的時候，首先會對key按照CRC16算法計算出16bit的值（可以理解為就是做hash），然后得到的值對16384進(jìn)行取模

候選者：取模之后，自然就得到其中一個哈希槽，然后就可以將數(shù)據(jù)插入到分配至該哈希槽的Redis實例中

面試官：那問題就來了，現(xiàn)在客戶端通過hash算法算出了哈希槽的位置，那客戶端怎么知道這個哈希槽在哪臺Redis實例上呢？

候選者：是這樣的，在集群的中每個Redis實例都會向其他實例「傳播」自己所負(fù)責(zé)的哈希槽有哪些。這樣一來，每臺Redis實例就可以記錄著「所有哈希槽與實例」的關(guān)系了（：

候選者：有了這個映射關(guān)系以后，客戶端也會「緩存」一份到自己的本地上，那自然客戶端就知道去哪個Redis實例上操作了

面試官：那我又有問題了，在集群里也可以新增或者刪除Redis實例啊，這個怎么整？

候選者：當(dāng)集群刪除或者新增Redis實例時，那總會有某Redis實例所負(fù)責(zé)的哈希槽關(guān)系會發(fā)生變化

候選者：發(fā)生變化的信息會通過消息發(fā)送至整個集群中，所有的Redis實例都會知道該變化，然后更新自己所保存的映射關(guān)系

候選者：但這時候，客戶端其實是不感知的（：

候選者：所以，當(dāng)客戶端請求時某Key時，還是會請求到「原來」的Redis實例上。而原來的Redis實例會返回「moved」命令，告訴客戶端應(yīng)該要去新的Redis實例上去請求啦

候選者：客戶端接收到「moved」命令之后，就知道去新的Redis實例請求了，并且更新「緩存哈希槽與實例之間的映射關(guān)系」

候選者：總結(jié)起來就是：數(shù)據(jù)遷移完畢后被響應(yīng)，客戶端會收到「moved」命令，并且會更新本地緩存

面試官：那數(shù)據(jù)還沒完全遷移完呢？

候選者：如果數(shù)據(jù)還沒完全遷移完，那這時候會返回客戶端「ask」命令。也是讓客戶端去請求新的Redis實例，但客戶端這時候不會更新本地緩存

面試官：了解了

面試官：說白了就是，如果集群Redis實例存在變動，由于Redis實例之間會「通訊」

面試官：所以等到客戶端請求時，Redis實例總會知道客戶端所要請求的數(shù)據(jù)在哪個Redis實例上

面試官：如果已經(jīng)遷移完畢了，那就返回「move」命令告訴客戶端應(yīng)該去找哪個Redis實例要數(shù)據(jù)，并且客戶端應(yīng)該更新自己的緩存(映射關(guān)系)

面試官：如果正在遷移中，那就返回「ack」命令告訴客戶端應(yīng)該去找哪個Redis實例要數(shù)據(jù)

候選者：不愧是你...

面試官：那你知道為什么哈希槽是16384個嗎？

候選者：嗯，這個。是這樣的，Redis實例之間「通訊」會相互交換「槽信息」，那如果槽過多（意味著網(wǎng)絡(luò)包會變大），網(wǎng)絡(luò)包變大，那是不是就意味著會「過度占用」網(wǎng)絡(luò)的帶寬

候選者：另外一塊是，Redis作者認(rèn)為集群在一般情況下是不會超過1000個實例

候選者：那就取了16384個，即可以將數(shù)據(jù)合理打散至Redis集群中的不同實例，又不會在交換數(shù)據(jù)時導(dǎo)致帶寬占用過多

面試官：了解了

面試官：那你知道為什么對數(shù)據(jù)進(jìn)行分區(qū)在Redis中用的是「哈希槽」這種方式嗎？而不是一致性哈希算法

候選者：在我理解下，一致性哈希算法就是有個「哈希環(huán)」，當(dāng)客戶端請求時，會對Key進(jìn)行hash，確定在哈希環(huán)上的位置，然后順時針往后找，找到的第一個真實節(jié)點

候選者：一致性哈希算法比「傳統(tǒng)固定取?！沟暮锰幘褪牵喝绻褐行枰略龌騽h除某實例，只會影響一小部分的數(shù)據(jù)

候選者：但如果在集群中新增或者刪除實例，在一致性哈希算法下，就得知道是「哪一部分?jǐn)?shù)據(jù)」受到影響了，需要進(jìn)行對受影響的數(shù)據(jù)進(jìn)行遷移

面試官：嗯...

候選者：而哈希槽的方式，我們通過上面已經(jīng)可以發(fā)現(xiàn)：在集群中的每個實例都能拿到槽位相關(guān)的信息

候選者：當(dāng)客戶端對key進(jìn)行hash運算之后，如果發(fā)現(xiàn)請求的實例沒有相關(guān)的數(shù)據(jù)，實例會返回「重定向」命令告訴客戶端應(yīng)該去哪兒請求

候選者：集群的擴(kuò)容、縮容都是以「哈希槽」作為基本單位進(jìn)行操作，總的來說就是「實現(xiàn)」會更加簡單（簡潔，高效，有彈性）。過程大概就是把部分槽進(jìn)行重新分配，然后遷移槽中的數(shù)據(jù)即可，不會影響到集群中某個實例的所有數(shù)據(jù)。

面試官：那你了解「服務(wù)端 路由」的大致原理嗎？

候選者：嗯，服務(wù)端路由一般指的就是，有個代理層專門對接客戶端的請求，然后再轉(zhuǎn)發(fā)到Redis集群進(jìn)行處理

候選者：上次最后面試的時候，也提到了，現(xiàn)在比較流行的是Codis

候選者：它與Redis Cluster最大的區(qū)別就是，Redis Cluster是直連Redis實例的，而Codis則客戶端直連Proxy，再由Proxy進(jìn)行分發(fā)到不同的Redis實例進(jìn)行處理

候選者：在Codis對Key路由的方案跟Redis Cluster很類似，Codis初始化出1024個哈希槽，然后分配到不同的Redis服務(wù)器中

候選者：哈希槽與Redis實例的映射關(guān)系由Zookeeper進(jìn)行存儲和管理，Proxy會通過Codis DashBoard得到最新的映射關(guān)系，并緩存在本地上

面試官：那如果我要擴(kuò)容Codis Redis實例的流程是怎么樣的？

候選者：簡單來說就是：把新的Redis實例加入到集群中，然后把部分?jǐn)?shù)據(jù)遷移到新的實例上

候選者：大概的過程就是：1.「原實例」某一個Solt的部分?jǐn)?shù)據(jù)發(fā)送給「目標(biāo)實例」。2.「目標(biāo)實例」收到數(shù)據(jù)后，給「原實例」返回ack。3.「原實例」收到ack之后，在本地刪除掉剛剛給「目標(biāo)實例」的數(shù)據(jù)。4.不斷循環(huán)1、2、3步驟，直至整個solt遷移完畢

候選者：Codis也是支持「異步遷移」的，針對上面的步驟2，「原實例」發(fā)送數(shù)據(jù)后，不等待「目標(biāo)實例」返回ack，就繼續(xù)接收客戶端的請求。

候選者：未遷移完的數(shù)據(jù)標(biāo)記為「只讀」，不會影響到數(shù)據(jù)的一致性。如果對遷移中的數(shù)據(jù)存在「寫操作」，那會讓客戶端進(jìn)行「重試」，最后會寫到「目標(biāo)實例」上

候選者：還有就是，針對 bigkey，異步遷移采用了「拆分指令」的方式進(jìn)行遷移，比如有個set元素有10000個，那「原實例」可能就發(fā)送10000條命令給「目標(biāo)實例」，而不是一整個bigkey一次性遷移（因為大對象容易造成阻塞）

面試官：了解了。

本文總結(jié)：

• 分片集群誕生理由：寫性能在高并發(fā)下會遇到瓶頸&&無法無限地縱向擴(kuò)展（不劃算）

• 分片集群：需要解決「數(shù)據(jù)路由」和「數(shù)據(jù)遷移」的問題

• Redis Cluster數(shù)據(jù)路由：

  • Redis Cluster默認(rèn)一個集群有16384個哈希槽，哈希槽會被分配到Redis集群中的實例中
  • Redis集群的實例會相互「通訊」，交互自己所負(fù)責(zé)哈希槽信息（最終每個實例都有完整的映射關(guān)系）
  • 當(dāng)客戶端請求時，使用CRC16算法算出Hash值并模以16384，自然就能得到哈希槽進(jìn)而得到所對應(yīng)的Redis實例位置

• 為什么16384個哈希槽：16384個既能讓Redis實例分配到的數(shù)據(jù)相對均勻，又不會影響Redis實例之間交互槽信息產(chǎn)生嚴(yán)重的網(wǎng)絡(luò)性能開銷問題

• Redis Cluster 為什么使用哈希槽，而非一致性哈希算法：哈希槽實現(xiàn)相對簡單高效，每次擴(kuò)縮容只需要動對應(yīng)Solt（槽）的數(shù)據(jù)，一般不會動整個Redis實例

• Codis數(shù)據(jù)路由：默認(rèn)分配1024個哈希槽，映射相關(guān)信息會被保存至Zookeeper集群。Proxy會緩存一份至本地，Redis集群實例發(fā)生變化時，DashBoard更新Zookeeper和Proxy的映射信息

• Redis Cluster和Codis數(shù)據(jù)遷移：Redis Cluster支持同步遷移，Codis支持同步遷移&&異步遷移

  • 把新的Redis實例加入到集群中，然后把部分?jǐn)?shù)據(jù)遷移到新的實例上（在線）

歡迎關(guān)注我的微信公眾號【Java3y】來聊聊Java面試，對線面試官系列持續(xù)更新中！

【對線面試官-移動端】系列 一周兩篇持續(xù)更新中！

【對線面試官-電腦端】系列 一周兩篇持續(xù)更新中！

原創(chuàng)不易！！求三連??！