如何快速定位 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 查找特性[1]，能夠直接利用 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[2] 的，而且該代理是由咱們本身開發維護的，在代理層改造的成本徹底受控，所以咱們選擇了方案二，即在代理層進行收集上報。

 

大的方向肯定以後，須要考慮具體的細節，好比:

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 [3]

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

 

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

 

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

 

最終的方案

 

對前面方案進行優化的話，能夠從如下兩個方面入手:

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

 

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

 

仔細思考下來，邏輯上是成立的，由於到達業務的流量是負載均衡過的，不一樣實例上的流量是比較均勻的，差不太多的，基於這個局部能夠表明總體的原則，那麼單實例上的熱 key 就能夠表明全局的一個狀況。

另外，就易用性和使用體驗上來講，若是聚合的數據在進程內，咱們能夠提供 HOTKEY 相似的自定義命令，讓用戶經過 redis-cli 直接獲取。

 

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

 

實現上來講，每一個集羣會有一個全局的 Hotkey Collector，每一個 client 上有本身獨立的 Counter，Counter 依舊採用前面提到的 LFU[4] 算法，Collector 會定時地去收集每一個 Counter 的數據並進行聚合，聚合的時候不會使用真實的計數，而是使用機率計數[5]，而且爲了適應訪問模式的變化 counter 的值會隨着時間衰減，總體上與 redis lfu[6]很是相似。

 

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

 

注:

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

 

後續的規劃

 

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

 

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

 

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