redis叢集如何解決key不均勻。這裡的不均勻如果指的是key分配到不同節點上數量不均勻那麼可以採用Redis-Cluster叢集解決。

Redis-Cluster key分配的演算法

叢集的key並不是按一個節點一個節點順序儲存，一個存滿再存下一個節點。這樣會導致單點壓力很大，其他節點閒置的情況。在Redis-Cluster叢集方案中，資料的分配是按照槽位來進行分配的，每一個數據的鍵被雜湊函式對映到一個槽位，redis-3.0.0規定一共有16384個雜湊槽位。當需要在 Redis 叢集中放置一個 key-value 時，redis 會先對 key 使用 crc16 演算法算出一個結果，然後把結果對 16384 求餘數，這樣每個 key 都會對應一個編號在 0-16383 之間的雜湊槽，redis 會根據節點數量大致均等的將雜湊槽對映到不同的節點中。

對分散式儲存系統的架構和運維管理，如何保證每個 Node 的資料儲存容量和請求量儘量均衡，是非常重要的。本文介紹 Redis 大叢集運維過程中，常見導致資料和請求量“傾斜”的場景，及規避措施。Redis 資料容量或請求量嚴重”傾斜”的影響

以下從運維的角度解釋，Redis數十節點的叢集，出現數據容量和請求量傾斜情況下，存在的一些痛點：

少數或單個節點請求量”過熱”，導致 Redis 分散式系統失去可擴充套件效能力和叢集的意義，類似 MongoDB_id 欄位作為片鍵；導致運維容量規劃，擴容處理難度大；增大自動化配置管理難度；單叢集節點儘量統一引數配置；監控告警複雜（容量，QPS，連線數的閾值等）。

那我們再看生產環境中，常見導致 Redis 叢集嚴重“傾斜”的場景

Redis 叢集常見“傾斜”的場景

這類問題一般 DBA 規劃不當，業務鍵空間（keyspace）設計不合理等問題導致

DBA 在規劃叢集時或擴容後，導致資料槽（雜湊桶）位分配不均勻，引起記憶體容量、鍵個數和請求 QPS 傾斜；業務的鍵空間設計不合理，所謂“熱點key”，導致某少量 KEY 的 QPS 操作很大；這類節點 QPS 過載；程式大量使用 Keys hash tags, 可能導致某些資料槽位的鍵個數較多；程式存在大的叢集 key（hash，set，list等），導致大 key 所在節點的容量和 QPS 過高；工和師執行Monitor這類命令，導致當前節點client輸出緩衝區增大，used_memory_rss 被撐大，導致節點記憶體容量增大。

接下來，當叢集出現記憶體容量、鍵數量或 QPS 請求量嚴重傾斜時，我們應該排查定位問題。

Redis 叢集“傾斜”問題排查

檢查叢集每個分片的資料槽分配是否均勻

下面以 Redis Cluster 叢集為例確認叢集中，每個節點負責的資料槽位（slots）和 key 個數。下面 demo的部分例項存在不輕度“傾斜”，但不嚴重，可考慮進行reblance。

排查節點熱點 Key，確定 top commands

使用 redis-faina，當然有實時分析平臺就更好。從以下示例中，可見兩個字首 key 的 QPS 佔比基本各為 50%, 明顯熱點 key；也能看到auth命令的異常（top commands）。

程式是否大量使用 Keys hash tags

可能導致資料儲存記憶體量，QPS都不均勻的問題，可使用scan掃描keyspace是否有使用hash tags的，或使用monitor，vc-redis-sniffer。

程式是否使用較大的集合鍵

比如 1kw 個欄位的 hash key， 記憶體佔用在幾個 GB，這類集合 key 每次操作幾個欄位，很難從 proxy 或 sdk 發現 key 的大小。 可透過 redis-cli –bigkeys

確認是否因 monitor 命令引起的輸出緩衝區佔用記憶體過大的問題

這類情況基本 Redis 例項記憶體會快速增長，很快會出現回落。透過監測 client 輸出緩衝區使用情況：

檢視輸出緩衝區列表長度不為 0 的 client。 可見 monitor 佔用輸出緩衝區 370MB如何有效避免 Redis 叢集“傾斜”問題叢集部署和擴容處理，保證資料槽位分配平均；keyspace設計時，如何避免熱點key, 打散熱key；業務在鍵空間設計時，中儘量避免使用大的集合型別的Key，把key設計拆分；程式角度儘量避免使用keys hash tag；避免工程師直接使用keys,monitor等命令，導致輸出緩衝區堆積；合量配置 normal 的 client output buffer，建議設定 10MB（警示:和業務確認調整再修改，避免業務出錯）

在實際生產業務場景中，大規模叢集很難做到叢集的完全均衡，只是儘量保證不出現嚴重傾斜問題。