快捷導(dǎo)航

詳解redis big key 排查思路

更新時(shí)間：2023年06月11日 11:44:16 作者：村頭法師

本文主要介紹了詳解redis big key 排查思路，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧

定義big key

為了讓對(duì)redis較為陌生的朋友不清楚big key的含義有一定的認(rèn)知。我們先來(lái)定義一下Big Key。
一切因?yàn)榇?，而?dǎo)致redis去執(zhí)行命令，網(wǎng)絡(luò)傳輸而導(dǎo)致慢的key，都可以稱為Big Key。

一個(gè)String的值特別大
一個(gè)List的元素特別多
一個(gè)Hash的元素特別多
List、Hash中某個(gè)元素特別大

都可以稱為Big Key。

那具體，多大才算大呢？那其實(shí)要看你具體業(yè)務(wù)的容忍度了，并不是一個(gè)很嚴(yán)格的限制。

這是我在知乎上看到一個(gè)博主對(duì)Big Key 大小的定義：

一個(gè)STRING類型的Key，它的值為5MB（數(shù)據(jù)過(guò)大）
一個(gè)LIST類型的Key，它的列表數(shù)量為20000個(gè)（列表數(shù)量過(guò)多）
一個(gè)ZSET類型的Key，它的成員數(shù)量為10000個(gè)（成員數(shù)量過(guò)多）
一個(gè)HASH格式的Key，它的成員數(shù)量雖然只有1000個(gè)但這些成員的value總大小為100MB（成員體積過(guò)大）

我個(gè)人認(rèn)為他對(duì)這個(gè)值度量定義的門檻頗低了，我目前開發(fā)維護(hù)的系統(tǒng)中，對(duì)一個(gè)String的Key，認(rèn)為超過(guò)100KB就開始算大，超過(guò)1MB是嚴(yán)禁發(fā)生的。

如何排查Big Key

那如何排查Big Key呢？何時(shí)排查Big Key呢？

一般情況下，我們應(yīng)該在第一次上生產(chǎn)之前，對(duì)系統(tǒng)進(jìn)行全面的各項(xiàng)測(cè)試，其中就應(yīng)該包括Big Key 的排查。
其次，就是在生產(chǎn)運(yùn)行中，也許我們測(cè)試不夠全面、也許多次迭代下來(lái)會(huì)有新的Big Key，我們應(yīng)該由監(jiān)控系統(tǒng)進(jìn)行掃描排查。

對(duì)于Big Key的排查來(lái)說(shuō)，那應(yīng)該就是把所有的Key，按照我們的閾值進(jìn)行比對(duì)其占用的內(nèi)存大小，判斷其是否為Big Key。
而我們知道，對(duì)于Redis 這種高性能內(nèi)存緩存來(lái)說(shuō)，我們都盡量使用一個(gè)O(1)算法復(fù)雜度的命令來(lái)調(diào)用，性能最佳。
而全部Key進(jìn)行掃描，顯然是一個(gè)O(n)的復(fù)雜度，將會(huì)阻塞Redis 相當(dāng)長(zhǎng)的時(shí)間。

而群里的討論點(diǎn)在于：在壓測(cè)的過(guò)程中，對(duì)redis big key進(jìn)行掃描，并且盡量不影響性能。

那讓我們來(lái)看看傳統(tǒng)的方案，以及個(gè)人的奇思妙想。

官方解決方案

在官方文檔 Scanning for big keys中如下描述：

In this special mode, redis-cli works as a key space analyzer. It scans the dataset for big keys, but also provides information about the data types that the data set consists of. This mode is enabled with the --bigkeys option, and produces verbose output.

$ redis-cli --bigkeys
[00.00%] Biggest string found so far 'key-419' with 3 bytes
[05.14%] Biggest list   found so far 'mylist' with 100004 items
[35.77%] Biggest string found so far 'counter:__rand_int__' with 6 bytes
[73.91%] Biggest hash   found so far 'myobject' with 3 fields
-------- summary -------
Sampled 506 keys in the keyspace!
Total key length in bytes is 3452 (avg len 6.82)
Biggest string found 'counter:__rand_int__' has 6 bytes
Biggest   list found 'mylist' has 100004 items
Biggest   hash found 'myobject' has 3 fields
504 strings with 1403 bytes (99.60% of keys, avg size 2.78)
1 lists with 100004 items (00.20% of keys, avg size 100004.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
1 hashs with 3 fields (00.20% of keys, avg size 3.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)

也就是使用redis-cli --bigkeys 命令進(jìn)行掃描，并會(huì)按照strings、lists、sets、hashs、zsets統(tǒng)計(jì)。

The program uses the SCAN command, so it can be executed against a busy server without impacting the operations, however the -i option can be used in order to throttle the scanning process of the specified fraction of second for each SCAN command.

這個(gè)命令是通過(guò)SCAN指令進(jìn)行實(shí)現(xiàn)的，并不是一次性直接對(duì)redis完成掃描，對(duì)于已經(jīng)繁忙(處于)壓測(cè)的服務(wù)器不會(huì)完全影響業(yè)務(wù)進(jìn)行。
但是實(shí)際上，也會(huì)有一定的性能影響。這個(gè)方案，也是這位測(cè)開朋友在壓測(cè)時(shí)采用的方案。

不過(guò)，他忽略了(當(dāng)然，早期的客戶端不一定支持這一參數(shù))可以使用 -i 0.01參數(shù)可以更好的降低對(duì)redis服務(wù)器處理業(yè)務(wù)請(qǐng)求的影響。
-i 0.01代表著redis-cli這一客戶端在每執(zhí)行一次SCAN指令后，會(huì)暫停0.01秒的時(shí)間。
這一參數(shù)會(huì)導(dǎo)致big key 掃描本身耗時(shí)有一定增加，但是對(duì)redis服務(wù)器的壓力就是降低許多，畢竟0.01秒對(duì)redis這種高性能的中間件來(lái)說(shuō)，已經(jīng)是一段不斷的時(shí)間了。

所以，就目前來(lái)說(shuō)，最方便也最穩(wěn)妥的方式就是redis-cli --bigkeys -i 0.01。

解析RDB文件并統(tǒng)計(jì)

RDB文件作為redis的一個(gè)全量持久化文件。通過(guò)下載并對(duì)他的解析統(tǒng)計(jì)Big Key，這對(duì)Redis服務(wù)器的資源則沒有任何消耗，是十分合理的。
但是若是為了掃描Big Key，在壓測(cè)環(huán)境下執(zhí)行BGSAVE這樣的持久化指令，其fork進(jìn)程的過(guò)程也會(huì)產(chǎn)生一定的阻塞，在Redis對(duì)他的標(biāo)記上，也是@slow的。
所以掃描一個(gè)已經(jīng)產(chǎn)生的RDB文件是可取的，特意去持久化一次，理論上對(duì)Redis產(chǎn)生的阻塞也是不小的。那具體其耗時(shí)如何，也未進(jìn)行實(shí)驗(yàn)驗(yàn)證。

而這樣的一個(gè)工具：redis-rdb-tools 在github上也擁有4.8K的star，想必使用的用戶也是不少的。
但是，我注意到了一點(diǎn)，這個(gè)工程最后一次提交在2020年。
而截止目前，redis在其后已經(jīng)相繼發(fā)布了redis 6、redis 7等更高的版本，并且對(duì)于RDB文件的格式，在redis 7.0 已經(jīng)更新到了format 10。
這一“年久失修”的redis-rdb-tools 未必能夠解析新版本的RDB文件。

網(wǎng)絡(luò)統(tǒng)計(jì)

個(gè)人突發(fā)奇想，若是在網(wǎng)絡(luò)層面上，通過(guò)抓包進(jìn)行分析，對(duì)redis的TCP報(bào)文進(jìn)行復(fù)制，然后使用Redis對(duì)應(yīng)版本的RESP2、RESP3報(bào)文解析，不就可以分析這段時(shí)間內(nèi)，客戶端獲取過(guò)的Big Key了嗎？
這樣對(duì)redis服務(wù)器的CPU等資源就沒有什么消耗了。
當(dāng)然，這個(gè)方案也有很明顯的缺點(diǎn)，除了需要自行編寫工具去分析以外，還存在很多分析不到的位置。
例如一個(gè)LRANGE指令，對(duì)指定key的list進(jìn)行范圍掃描并返回:

LRANGE key start stop

它的復(fù)雜度是O(S+N)，其中S的復(fù)雜度與列表的HEAD或者TAIL的距離有關(guān)，而N則是范圍內(nèi)元素的個(gè)數(shù)。
所以當(dāng)S很大，而N很小的時(shí)候，返回給客戶端的數(shù)據(jù)量，其實(shí)還是小的，而它可能是一個(gè)Big Key，但是我們這個(gè)方案是沒有機(jī)會(huì)發(fā)現(xiàn)它了。

新增從節(jié)點(diǎn)

個(gè)人覺得這是一個(gè)很妙的方式，具有可行性，但是也比較浪費(fèi)，意義不是十分大的方案。

我們可以在壓測(cè)開始前，通過(guò)slave of 命令，將我們新起的一個(gè)redis節(jié)點(diǎn)作為壓測(cè)節(jié)點(diǎn)的從節(jié)點(diǎn)。并且這個(gè)節(jié)點(diǎn)對(duì)應(yīng)用不可見。
那么我們?cè)谶@個(gè)節(jié)點(diǎn)上進(jìn)行big key的統(tǒng)計(jì)，就對(duì)業(yè)務(wù)沒有任何影響了。