reids集群架構圖：
在這個圖中，每一個藍色的圈都代表着一個redis的服務器節點。它們任何兩個節點之間都是相互連通的(Gossip協議)。客戶端可以與任何一個節點相連接，然后就可以訪問集群中的任何一個節點。對其進行存取和其他操作。
那么redis是怎么做到的呢？首先，在redis的每一個節點上，有一個插槽（slot）可以理解為是一個可以存儲兩個數值的一個變量這個變量的取值范圍是：0-16383。還有一個就是cluster我個人把這個cluster理解為是一個集群管理的插件。當我們的存取的key到達的時候，redis會根據CRC16的算法得出一個結果，然后把結果對 16384 求余數，這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽，通過這個值，去找到對應的插槽所對應的節點，然后直接自動跳轉到這個對應的節點上進行存取操作。
還有就是因為如果集群的話，是有好多個redis一起工作的，那么，就需要這個集群不是那么容易掛掉，所以呢，理論上就應該給集群中的每個節點至少一個備用的redis服務。這個備用的redis稱為從節點（slave）。那么這個集群是如何判斷是否有某個節點掛掉了呢？
首先要說的是，每一個節點都存有這個集群所有主節點以及從節點的信息。
它們之間通過互相的ping-pong判斷是否節點可以連接上。如果有一半以上的節點去ping一個節點的時候沒有回應，集群就認為這個節點宕機了，然后去連接它的備用節點。如果某個節點和所有從節點全部掛掉，我們集群就進入faill狀態。還有就是如果有一半以上的主節點宕機，那么我們集群同樣進入發力了狀態。這就是我們的redis的投票機制
Redis cluster是一個去中心化、多實例Redis間進行數據共享的集群。由於被設計為無中心節點和無代理節點，Redis cluster可以實現集群節點的在線線性伸縮，並通過主從復制模型來提供一定程度的高可用行，在實際環境中某個節點故障不可用時，集群其他節點可以持續提供服務。
關於數據分片，Redis cluster並沒有采用一致性hash，而是引入了hash slot。整個集群共有16384個slot，這些slot被全部分配在各個節點中，並且可以在不同節點間遷移。而每個slot存放哪些數據是由key通過CRC16校驗后對16384取模來決定的。
為了使集群中部分節點故障或者失去聯系的情況下集群其他節點可以提供持續服務，Redis cluster 采用主從復制模型。簡單的說，就是每個對外提供服務的節點，我們稱之為master節點，並為每個master節點提供一個slave節點。當其中一個master節點故障時，其slave節點替代原有的master節點，以保證不會因為找不到slot而使整個集群不可用。
Redis cluster所具備的水平伸縮能力和高可用性。
注：對集群進行擴容收縮的工作，實際就是對slot的遷移，意味着進行數據遷移，過程挺消耗性能的，因此建議大家及時根據業務趨勢提前做好評估和規划工作，避免在高峰時段給服務器增加額外的壓力。
Slot機制的並發收益：
Slot機制還有一個很明顯的優勢，就是在處理並發的場景，因為它將數據集進行了分割，實際上減小了鎖的粒度，從而擴大了並發度。Java中的ConcurrentHashMap容器是應用這種機制來實現並發的典型的例子