1.前言

由于Redis主從復制模式和Redis哨兵模式采用的都是復制Master節(jié)點的數(shù)據(jù)，實現(xiàn)讀寫分離。但是這種設計存在一個嚴重的問題，它沒有真正意義上實現(xiàn)數(shù)據(jù)分片。兩個模式都有一個問題，不能水平擴容，并且這兩個模式的高可用特性都會受到Master主節(jié)點內存的限制。Redis較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復雜。所有Redis集群模式就是用來解決這個問題。

2. Redis Cluster集群模式

Redis Cluster是一種服務器Sharding技術，3.0版本開始正式提供。Redis集群搭建的方式有多種，例如使用zookeeper等，但從redis 3.0之后版本支持redis-cluster集群，Redis-Cluster采用無中心結構，每個節(jié)點保存數(shù)據(jù)和整個集群狀態(tài),每個節(jié)點都和其他所有 節(jié)點連接。其redis-cluster架構圖如下：

在這個圖中，每一個藍色的圈都代表著一個redis的服務器節(jié)點。它們任何兩個節(jié)點之間都是相互連通的。客戶端可以與任何一個節(jié)點相連接，然后就可以訪問集群中的任何一個節(jié)點。對其進行存取和其他操作。

其結構特點：

所有的redis節(jié)點彼此互聯(lián)(PING-PONG機制),內部使用二進制協(xié)議優(yōu)化傳輸速度和帶寬。

節(jié)點的fail是通過集群中超過半數(shù)的節(jié)點檢測失效時才生效。

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

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

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

2.1 Redis集群數(shù)據(jù)分片

在redis的每一個節(jié)點上，都有這么兩個東西，一個是插槽（slot）可以理解為是一個可以存儲兩個數(shù)值的一個變量這個變量的取值范圍是：0-16383。還有一個就是cluster，可以理解為是一個集群管理的插件。當我們的存取的key到達的時候，redis會根據(jù)crc16的算法得出一個結果，然后把結果對 16384 求余數(shù)，這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽，通過這個值，去找到對應的插槽所對應的節(jié)點，然后直接自動跳轉到這個對應的節(jié)點上進行存取操作。

如果Redis是Redis Cluster的話，是有好多個redis一起工作的，那么，就需要這個集群不是那么容易掛掉，所以呢，理論上就應該給集群中的每個節(jié)點至少一個備用的Slave redis服務。這個備用的redis稱為從節(jié)點（slave）。

2.2 Redis Cluster 備份容錯機制

每一個節(jié)點都存有這個集群所有主節(jié)點以及從節(jié)點的信息。

它們之間通過互相的ping-pong判斷是否節(jié)點可以連接上。如果有一半以上的節(jié)點去ping一個節(jié)點的時候沒有回應，集群就認為這個節(jié)點宕機了，然后去連接它的備用節(jié)點。如果某個節(jié)點和所有從節(jié)點全部掛掉，我們集群就進入Fail狀態(tài)。還有就是如果有一半以上的主節(jié)點宕機，那么我們集群同樣進入Fail狀態(tài)。這就是我們的redis的投票機制，具體原理如下圖所示：

• 投票過程是集群中所有master參與,如果半數(shù)以上master節(jié)點與master節(jié)點通信超時(cluster-node-timeout),認為當前master節(jié)點掛掉.

總結

以上是生活随笔為你收集整理的Redis：Redis集群模式(Cluster)原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。