在 redis 中，熱 key 指的是那些在一段時(shí)間內(nèi)訪問頻次比較高的鍵值，具體到業(yè)務(wù)上，商品的限時(shí)搶購、瞬時(shí)的新聞熱點(diǎn)或某個(gè)全局性的資源，都極有可能產(chǎn)生熱點(diǎn) key。
熱點(diǎn) key 的出現(xiàn)可能會(huì)對(duì)系統(tǒng)的穩(wěn)定性和可用性造成影響，比如對(duì)應(yīng)節(jié)點(diǎn)的網(wǎng)卡帶寬被打滿，出現(xiàn)丟包重傳，請(qǐng)求波動(dòng)耗時(shí)大幅上升，甚至影響到業(yè)務(wù)的正常使用，引發(fā)用戶的不滿。因此，在日常的工作中，我們需要著重避免這種情況的出現(xiàn)，比如在設(shè)計(jì)和編碼階段避免引入全局性熱 key，或者在設(shè)計(jì)時(shí)考慮熱 key 出現(xiàn)時(shí)的應(yīng)對(duì)方案。
可能的方案
熱點(diǎn) key 即使我們?cè)谠O(shè)計(jì)和開發(fā)時(shí)已經(jīng)極力避免，然而在真實(shí)的生產(chǎn)環(huán)境中還是可能依舊存在的，導(dǎo)致其繼續(xù)出現(xiàn)的原因有以下幾種:
- 有一些邊界 case 沒有考慮到
- 異常或非預(yù)期的流量
既然不可能完全避免，我們就需要有一種方法能夠在出問題的時(shí)候快速定位有沒有熱 key 以及熱 key 具體是啥，來幫助業(yè)務(wù)快速排障，定位問題的根源。如果要設(shè)計(jì)定位方案的話，我們可以從 Redis 請(qǐng)求路徑上的節(jié)點(diǎn)來著手，比如在客戶端、中間層和服務(wù)端，具體來說如下:
- 客戶端收集上報(bào)改動(dòng) Redis SDK，記錄每個(gè)請(qǐng)求，定時(shí)把收集到的數(shù)據(jù)上報(bào)，然后由一個(gè)統(tǒng)一的服務(wù)進(jìn)行聚合計(jì)算。方案直觀簡(jiǎn)單，但沒法適應(yīng)多語言架構(gòu)，一方面多語言 SDK 對(duì)齊是個(gè)問題，另外一方面后期 SDK 的維護(hù)升級(jí)會(huì)面臨比較大的困難，成本很高。
- 代理層收集上報(bào)如果所有的 Redis 請(qǐng)求都經(jīng)過代理的話，可以考慮改動(dòng) Proxy 代碼進(jìn)行收集，思路與客戶端基本類似。該方案對(duì)使用方完全透明，能夠解決客戶端 SDK 的語言異構(gòu)和版本升級(jí)問題，不過開發(fā)成本會(huì)比客戶端高些。
- Redis 數(shù)據(jù)定時(shí)掃描Redis 在 4.0 版本之后添加了 hotkeys 查找特性[1]，可以直接利用 redis-cli --hotkeys 獲取當(dāng)前 keyspace 的熱點(diǎn) key，實(shí)現(xiàn)上是通過 scan + object freq 完成的。該方案無需二次開發(fā)，能夠直接利用現(xiàn)成的工具，但由于需要掃描整個(gè) keyspace，實(shí)時(shí)性上比較差，另外掃描耗時(shí)與 key 的數(shù)量正相關(guān)，如果 key 的數(shù)量比較多，耗時(shí)可能會(huì)非常長(zhǎng)。
- Redis 節(jié)點(diǎn)抓包解析在可能存在熱 key 的節(jié)點(diǎn)上(流量?jī)A斜判斷)，通過 tcpdump 抓取一段時(shí)間內(nèi)的流量并上報(bào)，然后由一個(gè)外部的程序進(jìn)行解析、聚合和計(jì)算。該方案無需侵入現(xiàn)有的 SDK 或者 Proxy 中間件，開發(fā)維護(hù)成本可控，但也存在缺點(diǎn)的，具體是熱 key 節(jié)點(diǎn)的網(wǎng)絡(luò)流量和系統(tǒng)負(fù)載已經(jīng)比較高了，抓包可能會(huì)情況進(jìn)一步惡化。
Redis 的 Monitor 命令不在考慮之列，原因是開銷比較大，單個(gè) monitor 的 client 會(huì)降低 50% 的系統(tǒng)吞吐，更多詳情見: https://redis.io/commands/monitor
我們的選擇
由于在餓了么內(nèi)部，所有的 Redis 請(qǐng)求都是經(jīng)過透明代理 Samaritan[2] 的，并且該代理是由我們自己開發(fā)維護(hù)的，在代理層改造的成本完全受控，因此我們選擇了方案二，即在代理層進(jìn)行收集上報(bào)。
大的方向確定之后，需要考慮具體的細(xì)節(jié)，比如:
- 記錄所有請(qǐng)求如何能夠保證不占用過多的內(nèi)存甚至 OOM ?
- 記錄所有請(qǐng)求如何能夠保證代理的性能, 請(qǐng)求耗時(shí)不會(huì)有明顯的上升?
針對(duì)第 1 點(diǎn)，既然我們只關(guān)心熱 key 而不是要統(tǒng)計(jì)所有 key 的 counter，那么就可以用 LFU 只保留訪問頻次最高的，第 2 點(diǎn)則需要結(jié)合代理具體的實(shí)現(xiàn)去考慮。
下圖是代理內(nèi)部的實(shí)現(xiàn)方案, 略去了一些無關(guān)的細(xì)節(jié):
注:
- 每個(gè) redis node 會(huì)創(chuàng)建一個(gè)與之對(duì)應(yīng)的唯一的 client，其上的所有請(qǐng)求都采用 pipeline 執(zhí)行
- 每個(gè) client 內(nèi)部都有自己的 Hotkey Collector，不同 Collector 間相互獨(dú)立
Hotkey Collector 內(nèi)部結(jié)構(gòu)如下所示，包含 LFU Counter、Syncer 和 Etrace Client 三部分:
Etrace 是一個(gè)內(nèi)部的應(yīng)用監(jiān)控平臺(tái)，類似的開源產(chǎn)品是 CAT [3]
基本的工作流程是，LFU Counter 負(fù)責(zé)記錄 key 的訪問頻次，Syncer 會(huì)定期將統(tǒng)計(jì)數(shù)據(jù)通過 Etrace Client 發(fā)送給遠(yuǎn)端的服務(wù)器。另外，為了避免向服務(wù)端發(fā)送過多無效的數(shù)據(jù)，內(nèi)部會(huì)預(yù)先設(shè)置一個(gè)閾值，超過閾值的才發(fā)送到服務(wù)端。
按照預(yù)先的設(shè)計(jì)，我們將會(huì)有一個(gè)實(shí)時(shí)計(jì)算的服務(wù)去拉取 Etrace 上的數(shù)據(jù)，進(jìn)行聚合計(jì)算得到當(dāng)前的熱點(diǎn) key。但不幸地是代理中間件改造上線后的很長(zhǎng)一段時(shí)間內(nèi)，這個(gè)實(shí)時(shí)計(jì)算服務(wù)的開發(fā)都未被提上日程，分析下來主要是 ROI 低和維護(hù)成本高，因此在業(yè)務(wù)上如果要查熱 key 就只能在 Etrace 上手動(dòng)戳 event 碰運(yùn)氣比如：
由于使用起來很麻煩，用戶在第一次體驗(yàn)之后基本就放棄了，不會(huì)再用第二次，甚至連我們自己都不愿意使用… 在當(dāng)時(shí)我們急需要找到一種更好的方案去解決用戶體驗(yàn)和系統(tǒng)復(fù)雜度的問題，讓該特性能真正地賦能于業(yè)務(wù)。
最終的方案
對(duì)前面方案進(jìn)行優(yōu)化的話，可以從以下兩個(gè)方面入手:
- 如何在不增加實(shí)時(shí)計(jì)算組件提升成本的前提下高效地聚合數(shù)據(jù)?
- 如何提升用戶體驗(yàn)，讓用戶方便地使用?
針對(duì)第一點(diǎn)，當(dāng)時(shí)第一個(gè)想法是能不能把聚合邏輯放在代理進(jìn)程內(nèi)，這樣的話就不用再依賴任何外部組件，可以降低整個(gè)系統(tǒng)的復(fù)雜度和維護(hù)成本。但這里會(huì)有個(gè)問題，之前設(shè)計(jì)外部聚合組件的初衷是為了聚合不同機(jī)器的數(shù)據(jù)，現(xiàn)在采用單機(jī)數(shù)據(jù)會(huì)不會(huì)有問題，邏輯是不是站得住腳？
仔細(xì)思考下來，邏輯上是成立的，因?yàn)榈竭_(dá)業(yè)務(wù)的流量是負(fù)載均衡過的，不同實(shí)例上的流量是比較均勻的，差不太多的，基于這個(gè)局部可以代表整體的原則，那么單實(shí)例上的熱 key 就可以代表全局的一個(gè)情況。
另外，就易用性和使用體驗(yàn)上來說，如果聚合的數(shù)據(jù)在進(jìn)程內(nèi)，我們可以提供 HOTKEY 類似的自定義命令，讓用戶通過 redis-cli 直接獲取。
最終的方案如下，已略去無關(guān)細(xì)節(jié):
實(shí)現(xiàn)上來說，每個(gè)集群會(huì)有一個(gè)全局的 Hotkey Collector，每個(gè) client 上有自己獨(dú)立的 Counter，Counter 依舊采用前面提到的 LFU[4] 算法，Collector 會(huì)定時(shí)地去收集每個(gè) Counter 的數(shù)據(jù)并進(jìn)行聚合，聚合的時(shí)候不會(huì)使用真實(shí)的計(jì)數(shù)，而是使用概率計(jì)數(shù)[5]，并且為了適應(yīng)訪問模式的變化 counter 的值會(huì)隨著時(shí)間衰減，整體上與 redis lfu[6]非常類似。
下面是一個(gè)生產(chǎn)環(huán)境的真實(shí)例子，展示了近一段時(shí)間內(nèi)比較熱的 key:
注:
- 默認(rèn)使用的 log factor 因子是 10，counter 值每分鐘衰減一半
- Collector 默認(rèn)的容量是 32，只記錄請(qǐng)求頻次最高的 32 個(gè) key
- 輸出的結(jié)果與 redis-cli --hotkeys 非常類似，counter 具體含義可以參考 Using Redis as an LRU cache[7] 一文末尾表格
后續(xù)的規(guī)劃
當(dāng)前的方案雖然能夠快速定位系統(tǒng)中的熱 key，但并沒有真正解決熱 key 本身帶來的問題，仍舊需要業(yè)務(wù)方自行改造或者將那些熱點(diǎn) key 調(diào)度到單獨(dú)的節(jié)點(diǎn)上，成本是比較高的，甚至有的業(yè)務(wù)還會(huì)自己做 local cache。
本著更好地服務(wù)于客戶的原則，我們后面將會(huì)考慮在代理內(nèi)實(shí)現(xiàn)熱點(diǎn) key 的緩存，不過在代理內(nèi)實(shí)現(xiàn)緩存的話需要先解決內(nèi)存占用、數(shù)據(jù)一致性和性能的問題，這塊暫時(shí)還沒有非常好的方案，仍舊在調(diào)研之中，好的消息是 Redis 6 計(jì)劃實(shí)現(xiàn) server-assisted client side caching[8]，如果有可能的話我們會(huì)第一時(shí)間考慮對(duì)接。
最后，熱 key 實(shí)時(shí)收集的功能已經(jīng)上線，并且也進(jìn)行了開源，相關(guān)源代碼可以在 Samaritan 中找到，有興趣的朋友可以進(jìn)行嘗試，有問題和想法也歡迎提 issue 或者直接與我交流。
作者簡(jiǎn)介：餓了么 CI框架工具部緩存組 韓亮
分享自：https://mp.weixin.qq.com/s/rZs-oWBGGYtNKLMpI0-tXw
