Redis集群Cluster

 

　　Redis Cluster 是社區版推出的 Redis 分布式集群解決方案，主要解決 Redis 分布式方面的需求，比
如，當遇到單機內存，並發和流量等瓶頸的時候，Redis Cluster 能起到很好的負載均衡的目的。
Redis Cluster 集群節點最小配置 6 個節點以上（3 主 3 從），其中主節點提供讀寫操作，從節點作為
備用節點，不提供請求，只作為故障轉移使用。

　　Redis Cluster 采用虛擬槽分區，所有的鍵根據哈希函數映射到 0～16383 個整數槽內，每個節點負責維
護一部分槽以及槽所映射的鍵值數據

 

 

 

 

原理

 redis-cluster設計 Redis-Cluster采用無中心結構，每個節點保存數據和整個集群狀態,每個節點都
和其他所有節點連接。

 

　　其結構特點：

　　1、所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬。

　　2、節點的fail是通過集群中超過半數的節點檢測失效時才生效。

　　3、客戶端與redis節點直連,不需要中間proxy層.客戶端不需要連接集群所有節點,連接集群中任何一個可用節點即可。

　　4、redis-cluster把所有的物理節點映射到[0-16383]slot上（不一定是平均分配）,cluster 負責維護node<->slot<->value。

　　5、Redis集群預分好16384個桶，當需要在 Redis 集群中放置一個 key-value 時，根據CRC16(key) mod 16384的值，決定將一個key放到哪個桶中。

　　　　　
a.redis cluster節點分配 現在我們是三個主節點分別是：A, B, C 三個節點，它們可以是一台機器上的
　　三個端口，也可以是三台不同的服務器。那么，采用哈希槽 (hash slot)的方式來分配16384個slot 的
　　話，它們三個節點分別承擔的slot 區間是：
　　　　節點A覆蓋0－5460;
　　　　節點B覆蓋5461－10922;
　　　　節點C覆蓋10923－16383.
　　　　獲取數據: 如果存入一個值，按照redis cluster哈希槽的算法： CRC16('key')384 = 6782。 那么就
　　會把這個key 的存儲分配到 B 上了。同樣，當我連接(A,B,C)任何一個節點想獲取'key'這個key時，
　　也會這樣的算法，然后內部跳轉到B節點上獲取數據
　　新增一個主節點: 新增一個節點D，redis cluster的這種做法是從各個節點的前面各拿取一部分slot
　　到D上，我會在接下來的實踐中實驗。大致就會變成這樣：
　　　　節點A覆蓋1365-5460
　　　　節點B覆蓋6827-10922
　　　　節點C覆蓋12288-16383
　　　　節點D覆蓋0-1364,5461-6826,10923-12287
　　同樣刪除一個節點也是類似，2移動完成后就可以刪除這個節點了。
b.Redis Cluster主從模式 redis cluster 為了保證數據的高可用性，加入了主從模式，一個主節點對應
　　一個或多個從節點，主節點提供數據存取，從節點則是從主節點拉取數據備份，當這個主節點掛掉后，
　　就會有這個從節點選取一個來充當主節點，從而保證集群不會掛掉
　　上面那個例子里, 集群有ABC三個主節點, 如果這3個節點都沒有加入從節點，如果B掛掉了，我們就無法
　　訪問整個集群了。A和C的slot也無法訪問。
　　所以我們在集群建立的時候，一定要為每個主節點都添加了從節點, 比如像這樣, 集群包含主節點A、B、
　　C, 以及從節點A1、B1、C1, 那么即使B掛掉系統也可以繼續正確工作。
　　B1節點替代了B節點，所以Redis集群將會選擇B1節點作為新的主節點，集群將會繼續正確地提供服
　　務。 當B重新開啟后，它就會變成B1的從節點。
　　不過需要注意，如果節點B和B1同時掛了，Redis集群就無法繼續正確地提供服務了。

 

 

 

優點：
無中心架構；
數據按照 slot 存儲分布在多個節點，節點間數據共享，可動態調整數據分布；
可擴展性：可線性擴展到 1000 多個節點，節點可動態添加或刪除；
高可用性：部分節點不可用時，集群仍可用。通過增加 Slave 做 standby 數據副本，能夠實現故
障自動 failover，節點之間通過 gossip 協議交換狀態信息，用投票機制完成 Slave 到 Master 的角
色提升；
降低運維成本，提高系統的擴展性和可用性。

缺點：
Client 實現復雜，驅動要求實現 Smart Client，緩存 slots mapping 信息並及時更新，提高了開發
難度，客戶端的不成熟影響業務的穩定性。目前僅 JedisCluster 相對成熟，異常處理部分還不完
善，比如常見的“max redirect exception”。
節點會因為某些原因發生阻塞（阻塞時間大於 clutser-node-timeout），被判斷下線，這種
failover 是沒有必要的。
數據通過異步復制，不保證數據的強一致性。
多個業務使用同一套集群時，無法根據統計區分冷熱數據，資源隔離性較差，容易出現相互影響的
情況。
Slave 在集群中充當“冷備”，不能緩解讀壓力，當然可以通過 SDK 的合理設計來提高 Slave 資源的
利用率。