Redis中如何應對熱key問題？下面本篇文章就來給大家介紹一下Redis緩存熱key問題的常用解決方案，希望對大家有所幫助！

做一些C端業務，不可避免的要引入一級緩存來代替數據庫的壓力并且減少業務響應時間，其實每次引入一個中間件來解決問題的同時，必然會帶來很多新的問題需要注意，比如上篇文章《數據庫與緩存一致性實戰》中提到的如何做緩存的一致性。那么其實還會有一些其他問題比如使用Redis作為一級緩存時可能帶來的熱key、大key等問題，本文我們就熱key（hot key）問題來討論，如何合理的解決熱key問題。

背景

熱key是什么問題，如何導致的？

一般來說，我們使用的緩存Redis都是多節點的集群版，對某個key進行讀寫時，會根據該key的hash計算出對應的slot，根據這個slot就能找到與之對應的分片(一個master和多個slave組成的一組redis集群)來存取該K-V。但是在實際應用過程中，對于某些特定業務或者一些特定的時段（比如電商業務的商品秒殺活動），可能會發生大量的請求訪問同一個key。所有的請求（且這類請求讀寫比例非常高）都會落到同一個redis server上，該redis的負載就會嚴重加劇，此時整個系統增加新redis實例也沒有任何用處，因為根據hash算法，同一個key的請求還是會落到同一臺新機器上，該機器依然會成為系統瓶頸2，甚至造成整個集群宕掉，若此熱點key的value 也比較大，也會造成網卡達到瓶頸，這種問題稱為 “熱key” 問題。【