定義
-
QPS集中在特定的Key。例如，Redis例項的總QPS（每秒查詢率）為10,000，而其中一個Key的每秒訪問量達到了7,000。
-
頻寬使用率集中在特定的Key。例如，對一個擁有上千個成員且總大小為1 MB的HASH Key每秒傳送大量的HGETALL操作請求。
-
CPU使用時間佔比集中在特定的Key。例如，對一個擁有數萬個成員的Key（ZSET型別）每秒傳送大量的ZRANGE操作請求。
問題
-
佔用大量的CPU資源，影響其他請求並導致整體效能降低。
-
叢集架構下，產生訪問傾斜，即某個資料分片被大量訪問，而其他資料分片處於空閒狀態，可能引起該資料分片的連線數被耗盡，新的連線建立請求被拒絕等問題。
-
在搶購或秒殺場景下，可能因商品對應庫存Key的請求量過大，超出Redis處理能力造成超賣。
-
熱Key的請求壓力數量超出Redis的承受能力易造成快取擊穿，即大量請求將被直接指向後端的儲存層，導致儲存訪問量激增甚至當機，從而影響其他業務。
產生的原因
-
預期外的訪問量陡增，如突然出現的爆款商品、訪問量暴漲的熱點新聞、直播間某主播搞活動帶來的大量刷屏點贊、遊戲中某區域發生多個工會之間的戰鬥涉及大量玩家等。
解決方案
- 在Redis叢集架構中對熱Key進行復制。在Redis叢集架構中，由於熱Key的遷移粒度問題，無法將請求分散至其他資料分片，導致單個資料分片的壓力無法下降。此時，可以將對應熱Key進行復制並遷移至其他資料分片，例如將熱Key foo複製出3個內容完全一樣的Key併名為foo2、foo3、foo4，將這三個Key遷移到其他資料分片來解決單個資料分片的熱Key壓力。
- 使用讀寫分離架構。如果熱Key的產生來自於讀請求，您可以將例項改造成讀寫分離架構來降低每個資料分片的讀請求壓力，甚至可以不斷地增加從節點。但是讀寫分離架構在增加業務程式碼複雜度的同時，也會增加Redis叢集架構複雜度。不僅要為多個從節點提供轉發層（如Proxy，LVS等）來實現負載均衡，還要考慮從節點數量顯著增加後帶來故障率增加的問題。Redis叢集架構變更會為監控、運維、故障處理帶來了更大的挑戰。
- 應用層使用本地快取。