redis 集群部署方式大部分採用類 Twemproxy 的方式進行部署。即通過 Twemproxy 對 redis key 進行分片計算，將 redis key 進行分片計算，分配到多個 redis 實例中的其中一個。tewmproxy 架構圖如下：

由於 Twemproxy 背後的多個 redis 實例在內存配置和 cpu 配置上都是一致的，所以一旦出現訪問量傾斜或者數據量傾斜，則可能會導致某個 redis 實例達到性能瓶頸，從而使整個集群達到性能瓶頸。

hot key出現造成集群訪問量傾斜

Hot key，即熱點 key，指的是在一段時間內，該 key 的訪問量遠遠高於其他的 redis key，導致大部分的訪問流量在經過 proxy 分片之後，都集中訪問到某一個 redis 實例上。hot key 通常在不同業務中，存儲著不同的熱點信息。比如

新聞應用中的熱點新聞內容；

活動系統中某個用戶瘋狂參與的活動的活動配置；

商城秒殺系統中，最吸引用戶眼球，性價比最高的商品信息；

……

解決方案

1. 使用本地緩存

在 client 端使用本地緩存，從而降低了redis集群對hot key的訪問量，但是同時帶來兩個問題：1、如果對可能成為 hot key 的 key 都進行本地緩存，那麼本地緩存是否會過大，從而影響應用程序本身所需的緩存開銷。2、如何保證本地緩存和redis集群數據的有效期的一致性。

針對這兩個問題，先不展開講，先將第二個解決方案。

2. 利用分片算法的特性，對key進行打散處理

我們知道 hot key 之所以是 hot key，是因為它只有一個key，落地到一個實例上。所以我們可以給hot key加上前綴或者後綴，把一個hotkey 的數量變成 redis 實例個數N的倍數M，從而由訪問一個 redis key 變成訪問 N * M 個redis key。

N*M 個 redis key 經過分片分佈到不同的實例上，將訪問量均攤到所有實例。

代碼如下：

在這個代碼中，通過一個大於等於 1 小於 M * N 的隨機數，得到一個 tmp key，程序會優先訪問tmp key，在得不到數據的情況下，再訪問原來的 hot key，並將 hot key的內容寫回 tmp key。值得注意的是，tmp key的過期時間是 hot key 的過期時間加上一個較小的隨機正整數，保證在 hot key 過期時，所有 tmp key 不會同時過期而造成緩存雪崩。這是一種通過坡度過期的方式來避免雪崩的思路，同時也可以利用原子鎖來寫入數據就更加的完美，減小db的壓力。

另外還有一件事值得一提，默認情況下，我們在生成 tmp key的時候，會把隨機數作為 hot key 的後綴，這樣符合redis的命名空間，方便 key 的收歸和管理。但是存在一種極端的情況，就是hot key的長度很長，這個時候隨機數不能作為後綴添加，原因是 Twemproxy 的分片算法在計算過程中，越靠前的字符權重越大，考後的字符權重則越小。也就是說對於key名，前面的字符差異越大，算出來的分片值差異也越大，更有可能分配到不同的實例（具體算法這裡不展開講）。所以，對於很長 key 名的 hot key，要對隨機數的放入做謹慎處理，比如放在在最後一個命令空間的最前面（eg：由原來的 space1:space2:space3_rand 改成 space1:space2:rand_space3）。