Redis多機經常使用架構-cluster

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