偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

如何快速定位 Redis 熱 key?

存儲 存儲軟件 Redis
在 Redis 中,熱key指的是那些在一段時間內(nèi)訪問頻次比較高的鍵值,具體到業(yè)務(wù)上,商品的限時搶購、瞬時的新聞熱點或某個全局性的資源,都極有可能產(chǎn)生熱點key。如何應(yīng)對熱點Key也是解決高并發(fā)的必備技能,本文作者條分縷析為你解答這個問題。

 [[320532]]

背景

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

熱點 key 的出現(xiàn)可能會對系統(tǒng)的穩(wěn)定性和可用性造成影響,比如對應(yīng)節(jié)點的網(wǎng)卡帶寬被打滿,出現(xiàn)丟包重傳,請求波動耗時大幅上升,甚至影響到業(yè)務(wù)的正常使用,引發(fā)用戶的不滿。因此,在日常的工作中,我們需要著重避免這種情況的出現(xiàn),比如在設(shè)計和編碼階段避免引入全局性熱 key,或者在設(shè)計時考慮熱 key 出現(xiàn)時的應(yīng)對方案。

可能的方案

熱點 key 即使我們在設(shè)計和開發(fā)時已經(jīng)極力避免,然而在真實的生產(chǎn)環(huán)境中還是可能依舊存在的,導(dǎo)致其繼續(xù)出現(xiàn)的原因有以下幾種:

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

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

1.客戶端收集上報

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

2.代理層收集上報

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

3.Redis 數(shù)據(jù)定時掃描

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

4.Redis 節(jié)點抓包解析

在可能存在熱 key 的節(jié)點上(流量傾斜判斷),通過 tcpdump 抓取一段時間內(nèi)的流量并上報,然后由一個外部的程序進行解析、聚合和計算。該方案無需侵入現(xiàn)有的 SDK 或者 Proxy 中間件,開發(fā)維護成本可控,但也存在缺點的,具體是熱 key 節(jié)點的網(wǎng)絡(luò)流量和系統(tǒng)負載已經(jīng)比較高了,抓包可能會情況進一步惡化。

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

我們的選擇

由于在餓了么內(nèi)部,所有的 Redis 請求都是經(jīng)過透明代理 Samaritan[2] 的,并且該代理是由我們自己開發(fā)維護的,在代理層改造的成本完全受控,因此我們選擇了方案二,即在代理層進行收集上報。

大的方向確定之后,需要考慮具體的細節(jié),比如:

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

針對第 1 點,既然我們只關(guān)心熱 key 而不是要統(tǒng)計所有 key 的 counter,那么就可以用 LFU 只保留訪問頻次最高的,第 2 點則需要結(jié)合代理具體的實現(xiàn)去考慮。

下圖是代理內(nèi)部的實現(xiàn)方案, 略去了一些無關(guān)的細節(jié):

 

注:

  • 每個 redis node 會創(chuàng)建一個與之對應(yīng)的唯一的 client,其上的所有請求都采用 pipeline 執(zhí)行
  • 每個 client 內(nèi)部都有自己的 Hotkey Collector,不同 Collector 間相互獨立

Hotkey Collector 內(nèi)部結(jié)構(gòu)如下所示,包含 LFU Counter、Syncer 和 Etrace Client 三部分:

 

Etrace 是一個內(nèi)部的應(yīng)用監(jiān)控平臺,類似的開源產(chǎn)品是 CAT [3]

基本的工作流程是,LFU Counter 負責(zé)記錄 key 的訪問頻次,Syncer 會定期將統(tǒng)計數(shù)據(jù)通過 Etrace Client 發(fā)送給遠端的服務(wù)器。另外,為了避免向服務(wù)端發(fā)送過多無效的數(shù)據(jù),內(nèi)部會預(yù)先設(shè)置一個閾值,超過閾值的才發(fā)送到服務(wù)端。

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

 

由于使用起來很麻煩,用戶在第一次體驗之后基本就放棄了,不會再用第二次,甚至連我們自己都不愿意使用… 在當(dāng)時我們急需要找到一種更好的方案去解決用戶體驗和系統(tǒng)復(fù)雜度的問題,讓該特性能真正地賦能于業(yè)務(wù)。

最終的方案

對前面方案進行優(yōu)化的話,可以從以下兩個方面入手:

  • 如何在不增加實時計算組件提升成本的前提下高效地聚合數(shù)據(jù)?
  • 如何提升用戶體驗,讓用戶方便地使用?

針對第一點,當(dāng)時第一個想法是能不能把聚合邏輯放在代理進程內(nèi),這樣的話就不用再依賴任何外部組件,可以降低整個系統(tǒng)的復(fù)雜度和維護成本。但這里會有個問題,之前設(shè)計外部聚合組件的初衷是為了聚合不同機器的數(shù)據(jù),現(xiàn)在采用單機數(shù)據(jù)會不會有問題,邏輯是不是站得住腳?

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

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

最終的方案如下,已略去無關(guān)細節(jié):

 

實現(xiàn)上來說,每個集群會有一個全局的 Hotkey Collector,每個 client 上有自己獨立的 Counter,Counter 依舊采用前面提到的 LFU[4] 算法,Collector 會定時地去收集每個 Counter 的數(shù)據(jù)并進行聚合,聚合的時候不會使用真實的計數(shù),而是使用概率計數(shù)[5],并且為了適應(yīng)訪問模式的變化 counter 的值會隨著時間衰減,整體上與 redis lfu[6]非常類似。

下面是一個生產(chǎn)環(huán)境的真實例子,展示了近一段時間內(nèi)比較熱的 key:

 

注:

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

后續(xù)的規(guī)劃

當(dāng)前的方案雖然能夠快速定位系統(tǒng)中的熱 key,但并沒有真正解決熱 key 本身帶來的問題,仍舊需要業(yè)務(wù)方自行改造或者將那些熱點 key 調(diào)度到單獨的節(jié)點上,成本是比較高的,甚至有的業(yè)務(wù)還會自己做 local cache。

本著更好地服務(wù)于客戶的原則,我們后面將會考慮在代理內(nèi)實現(xiàn)熱點 key 的緩存,不過在代理內(nèi)實現(xiàn)緩存的話需要先解決內(nèi)存占用、數(shù)據(jù)一致性和性能的問題,這塊暫時還沒有非常好的方案,仍舊在調(diào)研之中,好的消息是 Redis 6 計劃實現(xiàn) server-assisted client side caching[8],如果有可能的話我們會第一時間考慮對接。

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

[[320533]]

作者簡介:餓了么 CI框架工具部緩存組 韓亮

文中鏈接:

[1] https://github.com/antirez/redis/pull/4392

[2] https://github.com/samaritan-proxy/samaritan

[3] https://github.com/dianping/cat

[4] https://en.wikipedia.org/wiki/Least_frequently_used

[5] https://en.wikipedia.org/wiki/Approximate_counting_algorithm

[6] http://antirez.com/news/109

[7] https://redis.io/topics/lru-cache

[8] https://redis.io/topics/client-side-caching

 

責(zé)任編輯:武曉燕 來源: 高可用架構(gòu)
相關(guān)推薦

2024-05-29 12:47:27

2022-04-12 14:54:52

Rediskey

2025-02-10 09:22:40

2024-11-19 18:27:50

2019-09-18 08:06:08

Redis數(shù)據(jù)庫命令

2019-11-05 08:24:34

JavaOOM快速定位

2020-07-08 09:50:37

Java內(nèi)存快速定位

2023-08-24 22:13:31

2025-05-28 03:10:00

2025-01-14 09:19:47

2019-07-28 18:30:52

MySQL日志數(shù)據(jù)庫

2023-10-22 11:17:50

AOFRedis數(shù)據(jù)庫

2020-07-14 11:00:12

Spring BootRedisJava

2024-07-01 08:04:38

2024-11-21 16:47:55

2023-02-26 10:18:24

數(shù)據(jù)庫SQL語句

2020-09-02 17:28:26

Spring Boot Redis集成

2022-12-09 14:40:16

CPU進程快速定位

2018-11-21 09:57:44

命令行Linux文件

2022-02-07 08:55:57

Go程序代碼
點贊
收藏

51CTO技術(shù)棧公眾號