美團二面:如何解決Redis熱點key問題

前言

有位星球粉絲去美團面試，被問到：Redis的熱點Key是怎麼解決的？那如何比較全面地回答這個問題，讓面試官眼前一亮呢？

如果是我，我會按照這幾個維度

• 什麼是熱點key
• 熱點key會帶來哪些問題
• 哪些原因可能導致熱點key
• 如何監測熱點key
• 如何識別到熱點key
• 如何解決熱點key
• 熱點key引申的一些後端思維

1. 什麼是熱點key

在Redis中，我們把訪問頻率高的key，稱為熱點key。

如果某一熱點key的請求到服務器主機時，由於請求量特別大，可能會導致主機資源不足，甚至宕機，從而影響正常的服務。

2.熱點key會帶來哪些問題

主要會帶來這些問題: 資源過載或者內存資源緊張、負載不均衡、主從同步延遲、緩存擊穿.

• CPU資源過載：如果某個Key被頻繁訪問，處理這些請求的Redis實例可能出現CPU過載的情況，導致處理其他請求的能力下降，影響整體性能。
• 內存資源緊張：熱點Key會佔用Redis實例的大量內存資源，特別是如果這個Key的數據量較大，可能導致內存緊張，影響Redis的正常運行。
• 負載不均衡: 在Redis集群中，熱點Key可能集中在某個或某幾個節點上，導致這些節點的負載遠高於其他節點。這種不均衡會導致集群的整體性能下降
• 主從同步延遲：如果Redis處於主從模式，熱點Key的頻繁訪問會導致主節點壓力增加，進而導致主從同步延遲，產生數據不一致的風險。這種情況在高併發場景下尤為明顯。
• 緩存擊穿：當一個熱點Key的緩存失效後，大量請求直接穿透到Redis或後端數據庫，造成瞬時的請求風暴，特別影響後端系統的性能，甚至可能導致Redis實例或後端服務崩潰。

3. 哪些原因可能導致熱點key

很多原因都可能導致熱點key，我給大家列舉一下:

• 熱門數據: 比如電商平臺的一些爆款商品詳情頁、社交平臺的熱門帖子等，往往會被大量用戶頻繁訪問，從而形成熱點Key。

• 短時高併發：例如新聞網站上的突發新聞、秒殺活動中的商品信息等。這些Key的訪問量在短時間內劇增，容易形成熱點。

• 請求分片集中：在Redis集群中，某些固定名稱的Key可能通過哈希分片集中到同一個節點。當這些Key的訪問量突然激增時，該節點可能超出性能瓶頸，導致熱點Key問題。

4. 如何監測熱點key

既然熱點key可能帶來一些問題，我們如何去檢測redis的熱點key呢? 常見的方案以後這些:

• MONITOR命令：可以實時監控Redis服務器執行的所有命令。通過分析這些命令，可以觀察到哪些Key被頻繁訪問，識別出熱點Key。不過，MONITOR命令的開銷較大，一般只在調試階段使用。

• 自定義統計腳本：可以編寫Lua腳本或使用Redis的命令組合（如SCAN、TTL等）定期統計和記錄訪問頻率高的Key。

• Redis自帶的分析工具：在Redis 4.0及以上版本中，redis-cli提供了--hotkeys選項，可以幫助分析哪些Key是熱點Key。

• Redis監控工具：第三方監控工具（如RedisInsight、Prometheus等）可以實時監控Redis實例的性能數據，並通過設置監控指標和警報，自動檢測出訪問頻率異常高的Key。

• SLOWLOG命令：SLOWLOG可以記錄執行時間較長的命令，儘管它主要用於監控慢查詢，但如果某個Key的操作頻繁導致命令變慢，也可以通過此方法發現熱點Key。

5. 如何識別到熱點key

在日常開發中，識別Redis中的熱點Key可以通過以下幾種方法：

• 憑經驗判斷哪些是熱Key: 根據對業務的瞭解，判斷哪些數據是訪問頻率最高的。例如，電商系統中的商品詳情頁、社交平臺上的熱門帖子、用戶個人信息等數據通常容易成為熱點Key。

• 客戶端統計上報: 在Redis客戶端（如Jedis、Lettuce）中添加統計代碼，對每次對Redis的訪問進行記錄。可以統計每個Key的訪問次數，並定期上報到監控系統。

• 服務代理層上報: 如果系統中使用了Redis代理（如Twemproxy、Codis、Redis Cluster等），可以在代理層添加統計功能，對經過代理的Redis請求進行統計，記錄每個Key的訪問頻率。

6. 如何解決熱點key

常見的有這幾種方式：Redis集群擴容、將熱點Key分散到不同的服務器中、使用二級緩存（JVM本地緩存）

6.1 Redis集群擴容

通過增加Redis集群中的分片和副本，可以將負載分散到更多的服務器上，減輕單個節點的壓力。特別是對於讀操作，可以通過添加更多的副本來均衡讀流量。

優點：通過水平擴展，Redis可以處理更大的負載，特別是針對高併發的讀請求。

6.2 將熱點Key分散到不同的服務器

通過改變Key的結構（如添加隨機前綴），將同一個熱點Key拆分成多個Key，使其分佈在不同的Redis節點上，從而避免所有流量集中在一個節點上。

優點：有效避免了單點瓶頸，提高了Redis集群的整體吞吐量。

6.3 使用二級緩存

在應用層引入本地緩存（如Guava Cache、Caffeine等），將熱點數據緩存在JVM內存中，減少對Redis的直接訪問，從而降低Redis的壓力。

優點：減少了對Redis的讀請求，降低了熱點Key帶來的負載壓力。

7. 熱點key引申的一些後端思維

在熱點key整個思考的過程，其實我們有很多後端思維可以參考。比如緩存設計、負載均衡與分片策略

7.1 緩存設計

在解決熱點key問題的時候，我們提到用二級緩存來降低熱點key的壓力，其實在日常開發中，我們很多這種多級緩存的思想。

在系統設計中考慮多級緩存結構（如本地緩存 + Redis + CDN），減少對後端數據庫的壓力。每一級緩存應有合理的失效策略，以確保數據的準確性和一致性。

7.2 負載均衡與分片策略

redis的熱點key 帶來負載不均衡等問題。在日常開發中，我們可以在系統架構中引入有效的負載均衡策略，將請求均勻分配到不同的節點或實例上。負載均衡不僅限於Redis，還包括應用層、數據庫等。

在解決熱點key問題的時候，我們提到將熱點Key分散到不同的服務器、Redis集群擴容。日常開發中，我們可以做一些分片優化，根據業務需求優化數據分片策略，確保數據分佈的均衡，避免單點熱點。對於熱點Key，考慮自定義分片算法來分散負載。