Redis集群方案

1. 官方
   1. 主從模式
   2. 哨兵模式
   3. Redis Cluster
2. 社區(qū)
   1. Codis(豌豆莢團(tuán)隊(duì)開源)
   2. Twemproxy(Twitter團(tuán)隊(duì)開源)

官方

主從模式

架構(gòu)圖

image.png

1. 簡說
   1. 主從復(fù)制是部署多個(gè)副本節(jié)點(diǎn)，多個(gè)副本節(jié)點(diǎn)實(shí)時(shí)復(fù)制主節(jié)點(diǎn)的數(shù)據(jù)示血，當(dāng)主節(jié)點(diǎn)宕機(jī)時(shí)弹灭，我們有完整的副本節(jié)點(diǎn)可以使用
2. 優(yōu)點(diǎn)
   1. 高可靠性，主從實(shí)時(shí)備份恋拍，有效解決單節(jié)點(diǎn)數(shù)據(jù)丟失問題
   2. 可做讀寫分離，從庫分擔(dān)讀操作，緩解主庫讀壓力
3. 缺點(diǎn)
   1. 主庫異常需要手動(dòng)主從切換
   2. 主庫的寫能力受到單機(jī)的限制懊直，可以考慮分片
   3. 主庫的存儲(chǔ)能力受到單機(jī)的限制指巡，可以考慮Pika

哨兵模式

架構(gòu)圖

image.png

1. 簡說
   1. 是基于主從模式做的升級淑履，它能夠?yàn)镽edis提供了高可用性。相對于主從模式在主節(jié)點(diǎn)宕機(jī)導(dǎo)致不可寫的情況下藻雪，多了一個(gè)競選機(jī)制秘噪，即從所有的從節(jié)點(diǎn)競選出新的主節(jié)點(diǎn)。競選機(jī)制的實(shí)現(xiàn)勉耀，是依賴于在系統(tǒng)中啟動(dòng)一個(gè)sentinel（哨兵）進(jìn)程指煎。哨兵是一個(gè)獨(dú)立的進(jìn)程，作為進(jìn)程便斥，它會(huì)獨(dú)立運(yùn)行至壤。其原理是哨兵通過發(fā)送命令，等待Redis服務(wù)器響應(yīng)枢纠，從而監(jiān)控運(yùn)行的多個(gè)Redis實(shí)例
2. 哨兵
   1. 通過發(fā)送命令像街，讓Redis服務(wù)器返回監(jiān)控其運(yùn)行狀態(tài)，包括主服務(wù)器和從服務(wù)器
   2. 當(dāng)哨兵監(jiān)測到master宕機(jī)晋渺，會(huì)自動(dòng)將slave切換成master镰绎，然后通過發(fā)布訂閱模式通知其他的從服務(wù)器，修改配置文件木西，讓它們切換主機(jī)

多哨兵模式

架構(gòu)圖

image.png

1. 簡說
   哨兵進(jìn)程也存在單點(diǎn)問題畴栖，為此，我們可以部署多個(gè)哨兵八千，使用多個(gè)哨兵進(jìn)行監(jiān)控吗讶，sentinel可以通過發(fā)布與訂閱來自動(dòng)發(fā)現(xiàn)Redis集群上的其它sentinel。sentinel在發(fā)現(xiàn)其它sentinel進(jìn)程后恋捆，會(huì)將其放入一個(gè)列表中照皆，這個(gè)列表存儲(chǔ)了所有已被發(fā)現(xiàn)的sentinel，這樣就形成了多哨兵模式
2. 主觀下線和客觀下線
   1. 哨兵節(jié)點(diǎn)發(fā)送ping命令時(shí)鸠信，當(dāng)超過一定時(shí)間(down-after-millisecond)后纵寝，如果節(jié)點(diǎn)未回復(fù)，則哨兵認(rèn)為主觀下線。主觀下線表示當(dāng)前哨兵認(rèn)為該節(jié)點(diǎn)已經(jīng)下線爽茴，如果該節(jié)點(diǎn)為主數(shù)據(jù)庫葬凳，哨兵會(huì)進(jìn)一步判斷是夠需要對其進(jìn)行故障切換，這時(shí)候就要發(fā)送命令(SENTINEL is-master-down-by-addr)詢問其他哨兵節(jié)點(diǎn)是否認(rèn)為該主節(jié)點(diǎn)是主觀下線室奏，當(dāng)達(dá)到指定數(shù)量(quorum)時(shí)火焰，哨兵就會(huì)認(rèn)為是客觀下線
   2. 當(dāng)主節(jié)點(diǎn)客觀下線時(shí)就需要進(jìn)行主從切換，主從切換的步驟為
      1. 選出領(lǐng)頭哨兵
      2. 領(lǐng)頭哨兵所有的slave選出優(yōu)先級最高的從數(shù)據(jù)庫胧沫。優(yōu)先級可以通過slave-priority選項(xiàng)設(shè)置
      3. 如果優(yōu)先級相同昌简，則從復(fù)制的命令偏移量越大（即復(fù)制同步數(shù)據(jù)越多，數(shù)據(jù)越新）绒怨，越優(yōu)先
      4. 如果以上條件都一樣纯赎，則選擇run ID較小的從數(shù)據(jù)庫
      5. 選出一個(gè)從數(shù)據(jù)庫后，哨兵發(fā)送slave no one命令升級為主數(shù)據(jù)庫南蹂，并發(fā)送slaveof命令將其他從節(jié)點(diǎn)的主數(shù)據(jù)庫設(shè)置為新的主數(shù)據(jù)庫
3. 優(yōu)點(diǎn)
   1. 能夠解決 Redis 主從模式下的高可用切換問題
4. 缺點(diǎn)
   1. 部署相對 Redis 主從模式要復(fù)雜一些犬金，原理理解更繁瑣
   2. 哨兵選舉期間，不能對外提供服務(wù)
   3. 資源浪費(fèi)六剥，Redis 數(shù)據(jù)節(jié)點(diǎn)中 slave 節(jié)點(diǎn)作為備份節(jié)點(diǎn)不提供服務(wù)

Redis Cluster

架構(gòu)圖

image.png

1. 簡說

   1. Redis Cluster采用無中心結(jié)構(gòu)晚顷，每個(gè)節(jié)點(diǎn)保存數(shù)據(jù)和整個(gè)集群狀態(tài)，每個(gè)節(jié)點(diǎn)都和其他所有節(jié)點(diǎn)連接

2. 結(jié)構(gòu)特點(diǎn)

   1. 所有的redis節(jié)點(diǎn)彼此互聯(lián)(PING-PONG機(jī)制)疗疟，內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬
   2. 節(jié)點(diǎn)的fail是通過集群中超過半數(shù)的節(jié)點(diǎn)檢測失效時(shí)才生效
   3. 客戶端與redis節(jié)點(diǎn)直連该默，不需要中間proxy層，客戶端不需要連接集群所有節(jié)點(diǎn)策彤，連接集群中任何一個(gè)可用節(jié)點(diǎn)即可
   4. Redis Cluster把所有的物理節(jié)點(diǎn)映射到[0-16383]slot上（不一定是平均分配）,cluster負(fù)責(zé)維護(hù)node<->slot<->value
   5. Redis集群預(yù)分好16384個(gè)桶栓袖，當(dāng)需要在 Redis 集群中放置一個(gè) key-value 時(shí)，根據(jù) CRC16(key) mod 16384的值锅锨，決定將一個(gè)key放到哪個(gè)桶中
   6. Redis Cluster為了保證數(shù)據(jù)的高可用性叽赊，加入了主從模式，一個(gè)主節(jié)點(diǎn)對應(yīng)一個(gè)或多個(gè)從節(jié)點(diǎn)必搞，主節(jié)點(diǎn)提供數(shù)據(jù)存取，從節(jié)點(diǎn)則是從主節(jié)點(diǎn)拉取數(shù)據(jù)備份囊咏，當(dāng)這個(gè)主節(jié)點(diǎn)掛掉后恕洲，就會(huì)有這個(gè)從節(jié)點(diǎn)選取一個(gè)來充當(dāng)主節(jié)點(diǎn)，從而保證集群不會(huì)掛掉

3. 一致性哈希

   
   
   image.png

4. 擴(kuò)容

   
   
   image.png
   image.png
   1. 首先啟動(dòng)一個(gè) Redis 節(jié)點(diǎn)梅割，記為 M4
   2. 使用 cluster meet 命令霜第，讓新 Redis 節(jié)點(diǎn)加入到集群中。新節(jié)點(diǎn)剛開始都是主節(jié)點(diǎn)狀態(tài)户辞，由于沒有負(fù)責(zé)的槽泌类，所以不能接受任何讀寫操作笛洛，后續(xù)我們就給他遷移槽和填充數(shù)據(jù)
   3. 對 M4 節(jié)點(diǎn)發(fā)送 cluster setslot { slot } importing { sourceNodeId} 命令沿猜，讓目標(biāo)節(jié)點(diǎn)準(zhǔn)備導(dǎo)入槽的數(shù)據(jù)
   4. 對源節(jié)點(diǎn)，也就是 M1，M2食棕，M3 節(jié)點(diǎn)發(fā)送 cluster setslot { slot } migrating { targetNodeId} 命令，讓源節(jié)點(diǎn)準(zhǔn)備遷出槽的數(shù)據(jù)
   5. 源節(jié)點(diǎn)執(zhí)行 cluster getkeysinslot { slot } { count } 命令啡省，獲取 count 個(gè)屬于槽 { slot } 的鍵标沪，然后執(zhí)行步驟六的操作進(jìn)行遷移鍵值數(shù)據(jù)
   6. 在源節(jié)點(diǎn)上執(zhí)行 migrate { targetNodeIp} " " 0 { timeout } keys { key... } 命令，把獲取的鍵通過 pipeline 機(jī)制批量遷移到目標(biāo)節(jié)點(diǎn)苞轿，批量遷移版本的 migrate 命令在 Redis 3.0.6 以上版本提供
   7. 重復(fù)執(zhí)行步驟 5 和步驟 6 直到槽下所有的鍵值數(shù)據(jù)遷移到目標(biāo)節(jié)點(diǎn)
   8. 向集群內(nèi)所有主節(jié)點(diǎn)發(fā)送 cluster setslot { slot } node { targetNodeId } 命令茅诱，通知槽分配給目標(biāo)節(jié)點(diǎn)。為了保證槽節(jié)點(diǎn)映射變更及時(shí)傳播搬卒，需要遍歷發(fā)送給所有主節(jié)點(diǎn)更新被遷移的槽執(zhí)行新節(jié)點(diǎn)

5. 收縮

   
   
   image.png
   1. 首先需要確認(rèn)下線節(jié)點(diǎn)是否有負(fù)責(zé)的槽瑟俭，如果是，需要把槽遷移到其他節(jié)點(diǎn)契邀，保證節(jié)點(diǎn)下線后整個(gè)集群槽節(jié)點(diǎn)映射的完整性尔当。
   2. 當(dāng)下線節(jié)點(diǎn)不再負(fù)責(zé)槽或者本身是從節(jié)點(diǎn)時(shí)，就可以通知集群內(nèi)其他節(jié)點(diǎn)忘記下線節(jié)點(diǎn)蹂安，當(dāng)所有的節(jié)點(diǎn)忘記改節(jié)點(diǎn)后可以正常關(guān)閉椭迎。
   3. 下線節(jié)點(diǎn)需要將節(jié)點(diǎn)自己負(fù)責(zé)的槽遷移到其他節(jié)點(diǎn)，原理與之前節(jié)點(diǎn)擴(kuò)容的遷移槽過程一致田盈。
   4. 遷移完槽后畜号，還需要通知集群內(nèi)所有節(jié)點(diǎn)忘記下線的節(jié)點(diǎn)，也就是說讓其他節(jié)點(diǎn)不再與要下線的節(jié)點(diǎn)進(jìn)行 Gossip 消息交換允瞧。

6. 虛擬節(jié)點(diǎn)

   
   
   image.png
   1. 為了解決雪崩現(xiàn)象和數(shù)據(jù)傾斜現(xiàn)象简软，提出了虛擬節(jié)點(diǎn)這個(gè)概念。就是將真實(shí)節(jié)點(diǎn)計(jì)算多個(gè)哈希形成多個(gè)虛擬節(jié)點(diǎn)并放置到哈希環(huán)上述暂，定位算法不變痹升，只是多了一步虛擬節(jié)點(diǎn)到真實(shí)節(jié)點(diǎn)映射的過程，具體做法可以在服務(wù)器ip或主機(jī)名的后面增加編號來實(shí)現(xiàn)畦韭。

7. 優(yōu)點(diǎn)

   1. 無中心架構(gòu)疼蛾，數(shù)據(jù)按照 slot 存儲(chǔ)分布在多個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)間數(shù)據(jù)共享
   2. 可擴(kuò)展性：可線性擴(kuò)展到 1000 多個(gè)節(jié)點(diǎn)艺配，節(jié)點(diǎn)可動(dòng)態(tài)添加或刪除
   3. 高可用性：部分節(jié)點(diǎn)不可用時(shí)察郁，集群仍可用。通過增加 Slave 做 standby 數(shù)據(jù)副本转唉，能夠?qū)崿F(xiàn)故障自動(dòng) failover皮钠，節(jié)點(diǎn)之間通過 gossip 協(xié)議交換狀態(tài)信息，用投票機(jī)制完成 Slave 到 Master 的角色提升
   4. 降低運(yùn)維成本赠法，提高系統(tǒng)的擴(kuò)展性和可用性

8. 缺點(diǎn)

   1. Client 實(shí)現(xiàn)復(fù)雜麦轰，驅(qū)動(dòng)要求實(shí)現(xiàn) Smart Client，緩存 slots mapping 信息并及時(shí)更新，提高了開發(fā)難度款侵，客戶端的不成熟影響業(yè)務(wù)的穩(wěn)定性
   2. 數(shù)據(jù)通過異步復(fù)制末荐，不保證數(shù)據(jù)的強(qiáng)一致性
   3. Slave 在集群中充當(dāng)“冷備”，不能緩解讀壓力喳坠，當(dāng)然可以通過 SDK 的合理設(shè)計(jì)來提高 Slave 資源的利用率
   4. Key 批量操作限制鞠评，如使用 mset、mget 目前只支持具有相同 slot 值的 Key 執(zhí)行批量操作壕鹉。對于映射為不同 slot 值的 Key 由于 Keys 不支持跨 slot 查詢剃幌，所以執(zhí)行 mset、mget晾浴、sunion 等操作支持不友好
   5. Key 事務(wù)操作支持有限负乡，只支持多 key 在同一節(jié)點(diǎn)上的事務(wù)操作，當(dāng)多個(gè) Key 分布于不同的節(jié)點(diǎn)上時(shí)無法使用事務(wù)功能
   6. Key 作為數(shù)據(jù)分區(qū)的最小粒度脊凰，不能將一個(gè)很大的鍵值對象如 hash抖棘、list 等映射到不同的節(jié)點(diǎn)
   7. 不支持多數(shù)據(jù)庫空間，單機(jī)下的 redis 可以支持到 16 個(gè)數(shù)據(jù)庫狸涌，集群模式下只能使用 1 個(gè)數(shù)據(jù)庫空間切省，即 db0
   8. 復(fù)制結(jié)構(gòu)只支持一層，從節(jié)點(diǎn)只能復(fù)制主節(jié)點(diǎn)帕胆，不支持嵌套樹狀復(fù)制結(jié)構(gòu)
   9. Redis Cluster 不建議使用 pipeline 和 multi-keys 操作朝捆，減少 max redirect 產(chǎn)生的場景

社區(qū)

Codis(豌豆莢團(tuán)隊(duì)開源)

image.png

image.png

1. 組件：
   1. codis-proxy：客戶端連接的Redis代理服務(wù)，本身實(shí)現(xiàn)了Redis協(xié)議懒豹，表現(xiàn)很像原生的Redis （就像 Twemproxy）芙盘。一個(gè)業(yè)務(wù)可以部署多個(gè) codis-proxy，其本身是無狀態(tài)的
   2. codis-dashbaord：統(tǒng)一的控制中心脸秽，整合了數(shù)據(jù)轉(zhuǎn)發(fā)規(guī)則儒老、故障自動(dòng)恢復(fù)、數(shù)據(jù)在線遷移记餐、節(jié)點(diǎn)擴(kuò)容縮容驮樊、自動(dòng)化運(yùn)維API等功能
   3. codis-group：基于Redis 3.2.8版本二次開發(fā)的Redis Server，增加了異步數(shù)據(jù)遷移功能剥扣，每個(gè)Group包括1個(gè)Redis Master及至少1個(gè)Redis Slave巩剖，這樣做的好處是，如果當(dāng)前Master有問題钠怯，則運(yùn)維人員可通過Dashboard“自助式”切換到Slave，而不需要小心翼翼地修改程序配置文件曙聂。
   4. codis-fe：管理多個(gè)集群的UI界面
   5. zookeeper：Codis依賴ZooKeeper來存放數(shù)據(jù)路由表和codis-proxy節(jié)點(diǎn)的元信息晦炊，codis-config發(fā)起的命令會(huì)通過 ZooKeeper同步到各個(gè)存活的codis-proxy
   6. 它的功能非常全，除了請求轉(zhuǎn)發(fā)功能之外，還實(shí)現(xiàn)了在線數(shù)據(jù)遷移断国、節(jié)點(diǎn)擴(kuò)容縮容贤姆、故障自動(dòng)恢復(fù)等功能
2. 優(yōu)點(diǎn)
   1. 對客戶端透明,與codis交互方式和redis本身交互一樣
   2. 支持在線數(shù)據(jù)遷移,遷移過程對客戶端透明有簡單的管理和監(jiān)控界面
   3. 支持高可用,無論是redis數(shù)據(jù)存儲(chǔ)還是代理節(jié)點(diǎn)
   4. 自動(dòng)進(jìn)行數(shù)據(jù)的均衡分配
   5. 最大支持1024個(gè)redis實(shí)例,存儲(chǔ)容量海量高性能
3. 缺點(diǎn)
   1. 采用自有的redis分支,不能與原版的redis保持同步
   2. 如果codis的proxy只有一個(gè)的情況下, redis的性能會(huì)下降20%左右
   3. 某些命令不支持,比如事務(wù)命令muti

Twemproxy(Twitter團(tuán)隊(duì)開源)

后續(xù)補(bǔ)全

Q&A

1. redis cluster3主3從集群，如果有1臺主掛了稳衬，會(huì)怎樣霞捡？
   1. 為什么主節(jié)點(diǎn)至少要3個(gè)，因?yàn)橹鲝淖詣?dòng)故障轉(zhuǎn)移的時(shí)候薄疚，需要主節(jié)點(diǎn)進(jìn)行投票選舉碧信，掛了一個(gè)，還有兩個(gè)可以進(jìn)行投票
   2. 如果一對主從節(jié)點(diǎn)都掛了街夭，那么這一部分槽都不可用砰碴，也不會(huì)進(jìn)行自動(dòng)轉(zhuǎn)移到其他主節(jié)點(diǎn)，所以redis集群的高可用是依賴于節(jié)點(diǎn)的主從復(fù)制與主從間的自動(dòng)故障轉(zhuǎn)移板丽，但是其他節(jié)點(diǎn)的槽位還是正常使用
   3. 出現(xiàn)連續(xù)掛這種情況的場景呈枉，可能出現(xiàn)熱點(diǎn)key，或者出現(xiàn)大value值埃碱，導(dǎo)致新的主節(jié)點(diǎn)又掛了猖辫，根據(jù)監(jiān)控，業(yè)務(wù)排查
      1. 如果是qps高砚殿，考慮限流啃憎？或者拆分槽位？或者分散key分布瓮具？
      2. 如果是大value值荧飞，考慮是否不存redis？或者本身業(yè)務(wù)邏輯有問題名党？
2. 數(shù)據(jù)分片策略有哪些叹阔？
   1. 范圍分片，哈希分片传睹，一致性哈希算法耳幢，哈希槽
3. redis cluster的分片策略？
   1. redis cluster用的是哈希槽欧啤，主要的原因就是一致性哈希算法對于數(shù)據(jù)分布睛藻、節(jié)點(diǎn)位置的控制并不是很友好
   2. 哈希槽使用crc16算法，其實(shí)哈希槽的本質(zhì)和一致性哈希算法非常相似邢隧，不同點(diǎn)就是對于哈系暧。空間的定義。一致性哈希的空間是一個(gè)圓環(huán)倒慧，節(jié)點(diǎn)分布是基于圓環(huán)的按摘，無法很好的控制數(shù)據(jù)分布
   3. 而 redis cluster 的槽位空間是自定義分配的包券，類似于 windows 盤分區(qū)的概念。這種分區(qū)是可以自定義大小炫贤，自定義位置的
   4. 從一個(gè)節(jié)點(diǎn)將哈希槽移動(dòng)到另一個(gè)節(jié)點(diǎn)并不會(huì)停止服務(wù)溅固，所以無論添加刪除或者改變某個(gè)節(jié)點(diǎn)的哈希槽的數(shù)量都不會(huì)造成集群不可用的狀態(tài)
   5. 但一定要注意的是，對于槽位的轉(zhuǎn)移和分派兰珍，redis 集群是不會(huì)自動(dòng)進(jìn)行的侍郭，而是需要人工配置的。所以 redis 集群的高可用是依賴于節(jié)點(diǎn)的主從復(fù)制與主從間的自動(dòng)故障轉(zhuǎn)移

   6. 哈希槽結(jié)構(gòu)圖

      
      
      image.png
4. 哈希槽為什么是16384個(gè)掠河？
   1. 在redis節(jié)點(diǎn)發(fā)送心跳包時(shí)需要把所有的槽放到這個(gè)心跳包里亮元，以便讓節(jié)點(diǎn)知道當(dāng)前集群信息
   2. CRC16算法最多可分配65535個(gè)槽位，這個(gè)ping消息的消息頭太大了口柳，浪費(fèi)帶寬苹粟，2^14是作者在CRC16中權(quán)衡出的比較“合適”的一個(gè)數(shù)值
   3. 16384=16k，在發(fā)送心跳包時(shí)使用位圖存儲(chǔ)node跃闹，bitmap壓縮后是2k（2 * 8 (8 bit) * 1024(1k) = 2K）
   4. 集群節(jié)點(diǎn)越多嵌削，心跳包的消息體內(nèi)攜帶的數(shù)據(jù)越多。如果節(jié)點(diǎn)過1000個(gè)望艺，也會(huì)導(dǎo)致網(wǎng)絡(luò)擁堵
   5. 因此redis作者苛秕，不建議redis cluster節(jié)點(diǎn)數(shù)量超過1000個(gè)。那么對于節(jié)點(diǎn)數(shù)在1000以內(nèi)的redis cluster集群找默，16384個(gè)槽位夠用了艇劫。沒有必要拓展到65536個(gè)
5. 出現(xiàn)哈希碰撞怎么解決？
   1. 哈希算法是一定會(huì)出現(xiàn)這個(gè)問題的惩激，這個(gè)不在本次討論訪問
6. 一致性哈希是什么店煞？
   1. 為了解決哈希取余映射算法新增/減少節(jié)點(diǎn)的時(shí)候，需要全局重新哈希取余映射而存在
   2. 但是出現(xiàn)可能不對節(jié)點(diǎn)實(shí)際占據(jù)環(huán)上的區(qū)間大小不一风钻，所以出現(xiàn)虛擬節(jié)點(diǎn)來解決問題
   3. 虛擬節(jié)點(diǎn)就是通過對每個(gè)節(jié)點(diǎn)構(gòu)造出多個(gè)虛擬節(jié)點(diǎn)再進(jìn)行一致性哈希顷蟀，比如機(jī)器A，可以創(chuàng)建A-1骡技，A-2鸣个，A-3等虛擬節(jié)點(diǎn)，只要在這些節(jié)點(diǎn)上布朦，都放到機(jī)器A
7. 大數(shù)據(jù)場景常用方案囤萤？
   1. 起碼3主3從，默認(rèn)主節(jié)點(diǎn)進(jìn)行讀寫是趴，從節(jié)點(diǎn)只讀主節(jié)點(diǎn)的數(shù)據(jù)涛舍，不提供服務(wù)，可通過readonly命令唆途，將slave設(shè)置成可讀
   2. 在故障轉(zhuǎn)移階段做盅，需要由主節(jié)點(diǎn)投票選出哪個(gè)從節(jié)點(diǎn)成為新的主節(jié)點(diǎn)缤削；從節(jié)點(diǎn)選舉勝出需要的票數(shù)為N/2+1窘哈；其中N為主節(jié)點(diǎn)數(shù)量(包括故障主節(jié)點(diǎn))吹榴，但故障主節(jié)點(diǎn)實(shí)際上不能投票。
   3. 因此為了能夠在故障發(fā)生時(shí)順利選出從節(jié)點(diǎn)滚婉，集群中至少需要3個(gè)主節(jié)點(diǎn)(且部署在不同的物理機(jī)上)图筹。
   4. Redis Cluster單個(gè)集群主節(jié)點(diǎn)可以添加到不超過1000個(gè)，一臺機(jī)器16g的話让腹，擁有16t的內(nèi)存远剩，夠用了，再大的話骇窍，也會(huì)導(dǎo)致網(wǎng)絡(luò)擁堵瓜晤，還不如創(chuàng)建多個(gè)集群
   5. 同步信息是交換維護(hù)節(jié)點(diǎn)元數(shù)據(jù)信息，什么槽在什么節(jié)點(diǎn)腹纳，并不是數(shù)據(jù)
   6. codis之所以停止維護(hù)痢掠，可能也是因?yàn)楣俜竭@個(gè)玩意太好用了，個(gè)人看法嘲恍，畢竟從設(shè)計(jì)上來看足画，兩種是完全不同的方案