Redis Cluster 運維總結

集羣總結：

一、Redis Cluster數據分區規則採用虛擬槽方式（16384個槽），每一個節點負責一個部分槽和相關數據，實現數據和請求的負載均衡。

二、搭建集羣劃分四個步驟：準備節點、節點握手、分配槽、複製。redis-trib.rb工具用於快速搭建集羣。

三、集羣伸縮經過在節點之間移動槽和相關數據實現

- 擴展時根據槽遷移計劃把槽從源節點遷移到新節點

- 收縮時若是下線的節點有負責的槽須要遷移到其餘節點，在經過cluster forget命令讓集羣內全部節點忘記被下線節點

四、使用smart客戶端操做集羣達到通訊效率最大化，客戶端內部負責計算維護鍵值-> 槽 -> 節點的映射，用於快速定位到目標節點。

五、集羣自動故障轉移過程分爲故障發現和節點恢復，節點下線分爲主觀下線和客戶下線，當超過半數主節點認爲故障節點爲主觀下線時標記它爲客觀下線狀態。從節點負責對客觀下線的主節點觸發故障恢復流程，保證集羣的可用性。

六、開發運維常見問題包括：超大規模集羣帶寬消耗、pub/sub廣播問題，集羣傾斜問題，單機和集羣對比等。

 

思考-分佈式Redis不必定好

一、Redis Cluster：知足容量和性能的擴展性，不少業務「不須要」

大多數是客戶端性能會「下降」

命令沒法跨節點使用：mget、keys、scan、flush、sinter等

Lua和事務沒法跨節點使用

客戶端維護更復雜：SDK和應用自己消耗（例如更多的鏈接池）

二、不少場景Redis Sentinel 已經足夠好

 

 

一、節點和槽分配不均

redis-trib.rb info ip:port 查看節點、槽、鍵值分佈

redis-trib.rb rebalance ip:port 進行均衡（謹慎使用）

二、不一樣槽對應鍵值數量差別較大

CRC16 正常狀況下比較均勻

可能存在 hash_tag

cluster countkeysinslot {slot} 獲取槽對應鍵值個數 

三、包含bikey

bigkey ：例如大字符串、幾百萬的元素的hash、set等

從節點 ：redis-cli --bigkeys

優化 ：優化數據結構

四、請求傾斜

熱點key：重要的key或者bigkey

優化：

避免bigkey

熱鍵不要用hash_tag

當一致性不高時，能夠用本地緩存 + MQ

五、集羣讀寫分離

（1）只讀連接：集羣模式的從節點不接受任何讀寫請求

-重定向到負責槽的主節點

-readonly命令能夠讀：鏈接級別命令

（2）讀寫分離：更加複雜

- 一樣的問題：複製延遲、讀取過時數據、從節點故障

- 修改客戶端：cluster slaves {nodeId}

六、離線/在線遷移

（1）官方遷移工具：redis-trib.rb import

- 只能從單機遷移到集羣

- 不支持在線遷移：source須要停寫

- 不支持斷點續傳

- 單線程遷移：影響速度

./redis-trib.rb import --form 127.0.0.1:6388 --copy 127.0.0.1:7000

（2）在線遷移

- 惟品會 redis-migrate-tool

- 豌豆莢：redis-port

七、集羣限制

key批量操做支持有限：例如mget、mset必須在一個slot

key事物和Lua支持有限：操做的key必須在一個節點

key是數據分區的最小粒度：不支持bigkey分區

不支持多個數據庫：幾圈模式下只有一個db 0

複製只支持一層：不支持樹形複製結構