redis設計的原理：其實就是分庫分表，去中心化
1、集群是如何判斷是否有某個節點掛掉
首先要說的是，每一個節點都存有這個集群所有主節點以及從節點的信息。它們之間通過互相的ping-pong判斷是否節點可以連接上。如果有一半以上的節點去ping一個節點的時候沒有回應，集群就認為這個節點宕機了，然后去連接它的備用節點。
2、集群進入fail狀態的必要條件
A、某個主節點和所有從節點全部掛掉，我們集群就進入faill狀態。
B、如果集群超過半數以上master掛掉，無論是否有slave，集群進入fail狀態.
C、如果集群任意master掛掉,且當前master沒有slave.集群進入fail狀態
3.redis集群去中心化（所有Master節點並發處理讀寫）
集群中原則每個Master節點都有一個或多個Slave節點。集群中所有的Master節點都可以進行讀寫數據，不分主次，記redis集群式去中心化的。每個Master節點與Slave節點間通過Goossip協議內部通信，異步復制。不用我們瞎操心（所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬.），但是異步賦值會導致某些特定情況下的數據丟失，即，redis集群不能保證數據的強一致性
4.redis集群的分區規則：虛擬槽分區(槽：slot)
RedisCluster采用此分區，所有的鍵根據哈希函數(CRC16[key]&16383)映射到0－16383槽內，共16384個槽位，每個節點維護部分槽及槽所映射的鍵值數據
哈希函數: Hash()=CRC16[key]&16383 按位與
redis用虛擬槽分區原因：解耦數據與節點關系，節點自身維護槽映射關系，分布式存儲
5. redisCluster的缺陷（虛擬槽分區的缺點）
a，鍵的批量操作支持有限，比如mset, mget，如果多個鍵映射在不同的槽，就不支持了
b，鍵事務支持有限，當多個key分布在不同節點時無法使用事務，同一節點是支持事務
c，鍵是數據分區的最小粒度，不能將一個很大的鍵值對映射到不同的節點
d，不支持多數據庫，只有0，select 0
e，復制結構只支持單層結構，不支持樹型結構。
6.客戶端與redis集群交互方式
由於Cluster架構中無Proxy層，客戶端是直接與集群中的任意可用節點直接交互的，【話是這么說，但是一個請求是怎么找到集群中的一個節點的呢，redis有多種策略，一般使用CRC16去hash(key)計算改請求要分配到具體的哪一個節點上。然后才是 客戶端與節點的直接操作】對象保存到Redis之前先經過CRC16哈希到一個指定的Node上，