redis 集群部署方式大部分采用類 Twemproxy 的方式進(jìn)行部署南誊。即通過 Twemproxy 對(duì) redis key 進(jìn)行分片計(jì)算，將 redis key 進(jìn)行分片計(jì)算，分配到多個(gè) redis 實(shí)例中的其中一個(gè)聪全。tewmproxy 架構(gòu)圖如下：

由于 Twemproxy 背后的多個(gè) redis 實(shí)例在內(nèi)存配置和 cpu 配置上都是一致的泊藕，所以一旦出現(xiàn)訪問量傾斜或者數(shù)據(jù)量傾斜，則可能會(huì)導(dǎo)致某個(gè) redis 實(shí)例達(dá)到性能瓶頸难礼，從而使整個(gè)集群達(dá)到性能瓶頸娃圆。

hot key出現(xiàn)造成集群訪問量傾斜

Hot key，即熱點(diǎn) key蛾茉，指的是在一段時(shí)間內(nèi)讼呢，該 key 的訪問量遠(yuǎn)遠(yuǎn)高于其他的 redis key， 導(dǎo)致大部分的訪問流量在經(jīng)過 proxy 分片之后谦炬，都集中訪問到某一個(gè) redis 實(shí)例上悦屏。hot key 通常在不同業(yè)務(wù)中节沦，存儲(chǔ)著不同的熱點(diǎn)信息。比如

新聞應(yīng)用中的熱點(diǎn)新聞內(nèi)容础爬；

活動(dòng)系統(tǒng)中某個(gè)用戶瘋狂參與的活動(dòng)的活動(dòng)配置甫贯；

商城秒殺系統(tǒng)中，最吸引用戶眼球看蚜，性價(jià)比最高的商品信息叫搁；?

……

解決方案

1. 使用本地緩存

在 client 端使用本地緩存，從而降低了redis集群對(duì)hot key的訪問量供炎，但是同時(shí)帶來兩個(gè)問題：1渴逻、如果對(duì)可能成為 hot key 的 key 都進(jìn)行本地緩存，那么本地緩存是否會(huì)過大音诫，從而影響應(yīng)用程序本身所需的緩存開銷惨奕。2、如何保證本地緩存和redis集群數(shù)據(jù)的有效期的一致性纽竣。?

針對(duì)這兩個(gè)問題墓贿，先不展開講，先將第二個(gè)解決方案蜓氨。

2. 利用分片算法的特性聋袋，對(duì)key進(jìn)行打散處理

我們知道 hot key 之所以是 hot key，是因?yàn)樗挥幸粋€(gè)key穴吹，落地到一個(gè)實(shí)例上幽勒。所以我們可以給hot key加上前綴或者后綴，把一個(gè)hotkey 的數(shù)量變成 redis 實(shí)例個(gè)數(shù)N的倍數(shù)M港令，從而由訪問一個(gè) redis key 變成訪問 N * M 個(gè)redis key啥容。?

N*M 個(gè) redis key 經(jīng)過分片分布到不同的實(shí)例上，將訪問量均攤到所有實(shí)例顷霹。

代碼如下：

在這個(gè)代碼中咪惠，通過一個(gè)大于等于 1 小于 M * N 的隨機(jī)數(shù)，得到一個(gè) tmp key淋淀，程序會(huì)優(yōu)先訪問tmp key遥昧，在得不到數(shù)據(jù)的情況下，再訪問原來的 hot key朵纷，并將 hot key的內(nèi)容寫回 tmp key炭臭。值得注意的是，tmp key的過期時(shí)間是 hot key 的過期時(shí)間加上一個(gè)較小的隨機(jī)正整數(shù)袍辞，保證在 hot key 過期時(shí)鞋仍，所有 tmp key 不會(huì)同時(shí)過期而造成緩存雪崩。這是一種通過坡度過期的方式來避免雪崩的思路搅吁，同時(shí)也可以利用原子鎖來寫入數(shù)據(jù)就更加的完美威创，減小db的壓力落午。

另外還有一件事值得一提，默認(rèn)情況下那婉，我們?cè)谏?tmp key的時(shí)候板甘，會(huì)把隨機(jī)數(shù)作為 hot key 的后綴，這樣符合redis的命名空間详炬，方便 key 的收歸和管理盐类。但是存在一種極端的情況，就是hot key的長度很長呛谜，這個(gè)時(shí)候隨機(jī)數(shù)不能作為后綴添加在跳，原因是 Twemproxy 的分片算法在計(jì)算過程中，越靠前的字符權(quán)重越大隐岛，考后的字符權(quán)重則越小猫妙。也就是說對(duì)于key名，前面的字符差異越大聚凹，算出來的分片值差異也越大割坠，更有可能分配到不同的實(shí)例（具體算法這里不展開講）。所以妒牙，對(duì)于很長 key 名的 hot key彼哼，要對(duì)隨機(jī)數(shù)的放入做謹(jǐn)慎處理，比如放在在最后一個(gè)命令空間的最前面（eg：由原來的 space1:space2:space3_rand 改成 space1:space2:rand_space3）湘今。

big key 造成集群數(shù)據(jù)量傾斜

big key?敢朱，即數(shù)據(jù)量大的 key ，由于其數(shù)據(jù)大小遠(yuǎn)大于其他key摩瞎，導(dǎo)致經(jīng)過分片之后拴签，某個(gè)具體存儲(chǔ)這個(gè) big key 的實(shí)例內(nèi)存使用量遠(yuǎn)大于其他實(shí)例，造成旗们，內(nèi)存不足蚓哩，拖累整個(gè)集群的使用。big key 在不同業(yè)務(wù)上上渴，通常體現(xiàn)為不同的數(shù)據(jù)岸梨，比如：

論壇中的大型持久蓋樓活動(dòng)；

聊天室系統(tǒng)中熱門聊天室的消息列表驰贷；?

……

解決方案

對(duì) big key 進(jìn)行拆分

對(duì) big key 存儲(chǔ)的數(shù)據(jù) （big value）進(jìn)行拆分，變成value1洛巢，value2… valueN,

如果big value 是個(gè)大json 通過 mset 的方式括袒，將這個(gè) key 的內(nèi)容打散到各個(gè)實(shí)例中，減小big key 對(duì)數(shù)據(jù)量傾斜造成的影響稿茉。

如果big value 是個(gè)大list锹锰，可以拆成將list拆成芥炭。= list_1， list_2, list3, listN

其他數(shù)據(jù)類型同理恃慧。

既是big key 也是 hot key

在開發(fā)過程中园蝠，有些 key 不只是訪問量大，數(shù)據(jù)量也很大痢士，這個(gè)時(shí)候就要考慮這個(gè) key 使用的場景彪薛，存儲(chǔ)在redis集群中是否是合理的，是否使用其他組件來存儲(chǔ)更合適怠蹂；如果堅(jiān)持要用 redis 來存儲(chǔ)善延，可能考慮遷移出集群，采用一主一備（或1主多備）的架構(gòu)來存儲(chǔ)城侧。

其他

如何發(fā)現(xiàn) hot key易遣，big key

1. 事前-預(yù)判

在業(yè)務(wù)開發(fā)階段，就要對(duì)可能變成 hot key 嫌佑，big key 的數(shù)據(jù)進(jìn)行判斷豆茫，提前處理，這需要的是對(duì)產(chǎn)品業(yè)務(wù)的理解屋摇，對(duì)運(yùn)營節(jié)奏的把握揩魂，對(duì)數(shù)據(jù)設(shè)計(jì)的經(jīng)驗(yàn)。

2.事中-監(jiān)控和自動(dòng)處理

監(jiān)控

在應(yīng)用程序端摊册，對(duì)每次請(qǐng)求 redis 的操作進(jìn)行收集上報(bào);不推薦肤京，但是在運(yùn)維資源缺少的場景下可以考慮。開發(fā)可以繞過運(yùn)維搞定）茅特；

在proxy層忘分，對(duì)每一個(gè) redis 請(qǐng)求進(jìn)行收集上報(bào);（推薦，簡單直接影響邪仔蕖）

對(duì) redis 實(shí)例使用monitor命令統(tǒng)計(jì)熱點(diǎn)key（不推薦妒峦，高并發(fā)條件下會(huì)有造成redis 內(nèi)存爆掉的隱患）；

機(jī)器層面兵睛，Redis客戶端使用TCP協(xié)議與服務(wù)端進(jìn)行交互肯骇，通信協(xié)議采用的是RESP。如果站在機(jī)器的角度祖很，可以通過對(duì)機(jī)器上所有Redis端口的TCP數(shù)據(jù)包進(jìn)行抓取完成熱點(diǎn)key的統(tǒng)計(jì)（不推薦笛丙，公司每臺(tái)機(jī)器上的基本組件已經(jīng)很多了，別再添亂了）假颇；

自動(dòng)處理

通過監(jiān)控之后胚鸯，程序可以獲取 big key 和 hot key，再報(bào)警的同時(shí)笨鸡，程序?qū)?big key 和 hot key 進(jìn)行自動(dòng)處理姜钳√构冢或者通知程序猿利用一定的工具進(jìn)行定制化處理（在程序中對(duì)特定的key 執(zhí)行前面提到的解決方案）

3.事后

盡量還是不要事后了吧，都是血和淚的教訓(xùn)哥桥，不展開講辙浑。

謝謝閱讀，歡迎交流拟糕。