Redis-cluster：去中心化，中間件，集群中任意節點平等，任一節點可獲得全局的數據
Redis-cluster 拓撲圖：
架構演變及 cap 理論：
單機 Redis 屬於 cp 模型。
Redis-cluster 屬於 ap 模型
Redis-cluster 核心參數：
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 50000(毫秒)
cluster-migration-barrier 1
cluster-require-full-coverage no
cluster-slave-validity-factor
(node-timeout * slave-validity-factor) + repl-ping-slave-period
Redis-cluster 數據分布：預分槽（slot）
預分配 16384(slot), 根據 crc16(key) mod 16384的值，決定key 存放在哪個 slot里。
預分槽的方案介於“硬Hash”和“一致性Hash”之間，犧牲了一定的靈活性，但相比“一致性Hash“，數據的管理成本大大降低
Redis-cluster M-S
Redis-cluster 采用 一主多從
集群完整寫的步驟：
1. client 寫數據到 master
2. master 告知 client “ok”
3. master 同步數據到 slave
存在風險：
第二步驟成功后， mater crash，照常主從數據不一致
Redis-cluster 解決了 我們什么問題？
以前：
1. redis cpu 使用率>80%， 拆分redis實例，修改代碼，指向新的redis實例。
2 redis 內存使用超過標准，繼續拆分實例！
3 redis 流量增長，拆!
4. 單實例的高可用問題。
現在：
只需要 分配一組新的redis實例 加入 cluster， 遷移 slot 即可解決 資源 使用率問題。
Redis-cluster缺點：
1. 無法查看 幾號 slot 里 存有什么類型的keys，只能查看實例里存有多少slot 號。
2. 當 redis-cluster 中 一組節點全部掛掉， 將 丟失 指向 已經掛掉節點的 keys。 （根據 crc16算法）
Redis-cluster 無法處理的問題：
A. 在遇到 被爬蟲，強刷部分模塊， 容易出現 redis 線程上漲，堵塞 響應請求， 其根因是 存儲的redis key不合 理.
B. 部分hash key 存的過大，單個key里 存儲數據 超過1W。降低 redis 響應時間。
C. 程序邏輯問題， 導致 redis 實列 頻繁刷新 部分業務key.
D. 程序設計漏洞。
cluster經典架構
節點：
節點（Node）
一個集群由一個或多個節點組成，其中主節點（master）負責儲存鍵值對數據，而從節點（slave）則負責復制主節點。
注意：從節點不提供任何讀寫操作
分片：
分片（Sharding）
集群將整個數據庫分為16384（2 的 14 次方）個槽（slot）
每個主節點可以負責處理0 個至 16384 個槽
注意：集群只有在所有槽位均有主節點處理時，才能進入上線狀態並處理數據命令
槽位計算方式
命令執行：
槽位正確與槽位不正確
槽位正確：命令處理的鍵所在的槽，正好由接收命令的節點負責
槽位不正確：接收命令的節點並不包含鍵所在的槽位
槽位正確：
槽位不正確：
鍵 date 所在的槽 2022 並非由節點 7001 負責，7001向客戶端返回Redirection。
客戶端根據Redirection的指引，轉向至節點 7000，並重新發送命令。
Redirection的實現
Gossip協議內部通信
Redirection的實現之槽表（Slot table）
節點在接收到命令請求時，會通過槽表檢查鍵所在的槽是否由本節點處理：
如果是的話，那么節點直接執行命令；
如果不是的話，那么節點就從槽表里面提取出正確節點的地址信息，然后返回客戶端轉向錯誤。
Failover
集群中三個負責處理命令的主節點標記7000出現SDOWN
