如何快速定位 Redis 熱 key

背景

在 Redis 中，熱 key 指的是那些在一段時間內訪問頻次比較高的鍵值，具體到業務上，商品的限時搶購、瞬時的新聞熱點或某個全局性的資源，都極有可能產生熱點 key。

熱點 key 的出現可能會對系統的穩定性和可用性造成影響，比如對應節點的網卡帶寬被打滿，出現丟包重傳，請求波動耗時大幅上升，甚至影響到業務的正常使用，引發用戶的不滿。因此，在日常的工作中，我們需要着重避免這種情況的出現，比如在設計和編碼階段避免引入全局性熱 key，或者在設計時考慮熱 key 出現時的應對方案。

可能的方案

熱點 key 即使我們在設計和開發時已經極力避免，然而在真實的生產環境中還是可能依舊存在的，導致其繼續出現的原因有以下幾種:

• 有一些邊界 case 沒有考慮到
• 異常或非預期的流量

既然不可能完全避免，我們就需要有一種方法能夠在出問題的時候快速定位有沒有熱 key 以及熱 key 具體是啥，來幫助業務快速排障，定位問題的根源。如果要設計定位方案的話，我們可以從 Redis 請求路徑上的節點來着手，比如在客戶端、中間層和服務端，具體來說如下:

1. 客戶端收集上報

   改動 Redis SDK，記錄每個請求，定時把收集到的數據上報，然後由一個統一的服務進行聚合計算。方案直觀簡單，但沒法適應多語言架構，一方面多語言 SDK 對齊是個問題，另外一方面後期 SDK 的維護升級會面臨比較大的困難，成本很高。

2. 代理層收集上報

   如果所有的 Redis 請求都經過代理的話，可以考慮改動 Proxy 代碼進行收集，思路與客戶端基本類似。該方案對使用方完全透明，能夠解決客戶端 SDK 的語言異構和版本升級問題，不過開發成本會比客戶端高些。

3. Redis 數據定時掃描

   Redis 在 4.0 版本之後添加了 hotkeys 查找特性，可以直接利用 redis-cli --hotkeys 獲取當前 keyspace 的熱點 key，實現上是通過 scan + object freq 完成的。該方案無需二次開發，能夠直接利用現成的工具，但由於需要掃描整個 keyspace，實時性上比較差，另外掃描耗時與 key 的數量正相關，如果 key 的數量比較多，耗時可能會非常長。

4. Redis 節點抓包解析

   在可能存在熱 key 的節點上(流量傾斜判斷)，通過 tcpdump 抓取一段時間內的流量並上報，然後由一個外部的程序進行解析、聚合和計算。該方案無需侵入現有的 SDK 或者 Proxy 中間件，開發維護成本可控，但也存在缺點的，具體是熱 key 節點的網絡流量和系統負載已經比較高了，抓包可能會情況進一步惡化。

Redis 的 Monitor 命令不在考慮之列，原因是開銷比較大，單個 monitor 的 client 會降低 50% 的系統吞吐，更多詳情見: https://redis.io/commands/monitor

我們的選擇

由於在餓了麼內部，所有的 Redis 請求都是經過透明代理 Samaritan 的，並且該代理是由我們自己開發維護的，在代理層改造的成本完全受控，因此我們選擇了方案二，即在代理層進行收集上報。

大的方向確定之後，需要考慮具體的細節，比如:

1. 記錄所有請求如何能夠保證不佔用過多的內存甚至 OOM ?
2. 記錄所有請求如何能夠保證代理的性能, 請求耗時不會有明顯的上升?

針對第 1 點，既然我們只關心熱 key 而不是要統計所有 key 的 counter，那麼就可以用 LFU 只保留訪問頻次最高的，第 2 點則需要結合代理具體的實現去考慮。

下圖是代理內部的實現方案, 略去了一些無關的細節:

注:

• 每個 redis node 會創建一個與之對應的唯一的 client，其上的所有請求都採用 pipeline 執行
• 每個 client 內部都有自己的 Hotkey Collector，不同 Collector 間相互獨立

Hotkey Collector 內部結構如下所示，包含 LFU Counter、Syncer 和 Etrace Client 三部分:

Etrace 是一個內部的應用監控平臺，類似的開源產品是 CAT

基本的工作流程是，LFU Counter 負責記錄 key 的訪問頻次，Syncer 會定期將統計數據通過 Etrace Client 發送給遠端的服務器。另外，爲了避免向服務端發送過多無效的數據，內部會預先設置一個閾值，超過閾值的才發送到服務端。

按照預先的設計，我們將會有一個實時計算的服務去拉取 Etrace 上的數據，進行聚合計算得到當前的熱點 key。但不幸地是代理中間件改造上線後的很長一段時間內，這個實時計算服務的開發都未被提上日程，分析下來主要是 ROI 低和維護成本高，因此在業務上如果要查熱 key 就只能在 Etrace 上手動戳 event 碰運氣比如：

由於使用起來很麻煩，用戶在第一次體驗之後基本就放棄了，不會再用第二次，甚至連我們自己都不願意使用… 在當時我們急需要找到一種更好的方案去解決用戶體驗和系統複雜度的問題，讓該特性能真正地賦能於業務。

最終的方案

對前面方案進行優化的話，可以從以下兩個方面入手:

1. 如何在不增加實時計算組件提升成本的前提下高效地聚合數據?
2. 如何提升用戶體驗，讓用戶方便地使用?

針對第一點，當時第一個想法是能不能把聚合邏輯放在代理進程內，這樣的話就不用再依賴任何外部組件，可以降低整個系統的複雜度和維護成本。但這裏會有個問題，之前設計外部聚合組件的初衷是爲了聚合不同機器的數據，現在採用單機數據會不會有問題，邏輯是不是站得住腳？

仔細思考下來，邏輯上是成立的，因爲到達業務的流量是負載均衡過的，不同實例上的流量是比較均勻的，差不太多的，基於這個局部可以代表整體的原則，那麼單實例上的熱 key 就可以代表全局的一個情況。

另外，就易用性和使用體驗上來說，如果聚合的數據在進程內，我們可以提供 HOTKEY 類似的自定義命令，讓用戶通過 redis-cli 直接獲取。

最終的方案如下，已略去無關細節:

實現上來說，每個集羣會有一個全局的 Hotkey Collector，每個 client 上有自己獨立的 Counter，Counter 依舊採用前面提到的 LFU 算法，Collector 會定時地去收集每個 Counter 的數據並進行聚合，聚合的時候不會使用真實的計數，而是使用概率計數，並且爲了適應訪問模式的變化 counter 的值會隨着時間衰減，整體上與 redis lfu 非常類似。

下面是一個生產環境的真實例子，展示了近一段時間內比較熱的 key:

注:

1. 默認使用的 log factor 因子是 10，counter 值每分鐘衰減一半
2. Collector 默認的容量是 32，只記錄請求頻次最高的 32 個 key
3. 輸出的結果與 redis-cli --hotkeys 非常類似，counter 具體含義可以參考 Using Redis as an LRU cache 一文末尾表格

後續的規劃

當前的方案雖然能夠快速定位系統中的熱 key，但並沒有真正解決熱 key 本身帶來的問題，仍舊需要業務方自行改造或者將那些熱點 key 調度到單獨的節點上，成本是比較高的，甚至有的業務還會自己做 local cache。

本着更好地服務於客戶的原則，我們後面將會考慮在代理內實現熱點 key 的緩存，不過在代理內實現緩存的話需要先解決內存佔用、數據一致性和性能的問題，這塊暫時還沒有非常好的方案，仍舊在調研之中，好的消息是 Redis 6 計劃實現 server-assisted client side caching，如果有可能的話我們會第一時間考慮對接。

最後，熱 key 實時收集的功能已經上線，並且也進行了開源，相關源代碼可以在 Samaritan 中找到，有興趣的朋友可以進行嘗試，有問題和想法也歡迎提 issue 或者直接與我交流。

作者簡介

韓亮，餓了麼 CI 框架工具部後端專家，在網關和透明代理領域有比較深入的探索，當前關注 Cloud Native 和 Service Mesh 等技術方向。