在使用 Redis 時，可能會出現(xiàn)請求響應(yīng)慢、網(wǎng)絡(luò)卡頓、數(shù)據(jù)丟失的情況。排查問題的時候，發(fā)現(xiàn)是 big keys 的問題。

什么是 big keys

在 Redis 中，一個字符串類型最大可以達(dá)到 512MB,其他非字符串類型的集合類型（list、set、hash、zset等）可以存儲 40 億個(2^32-1），但在實際業(yè)務(wù)場景中，并不需要這么大的內(nèi)存。而且對于一個請求量大的互聯(lián)網(wǎng)軟件，對數(shù)據(jù)的大小要求更加的嚴(yán)格。如果達(dá)到如下標(biāo)準(zhǔn)，就可以認(rèn)定是 big keys 了：

• String 類型的 key 對應(yīng)的值超過 5 MB。
• list、set、hash、zset等集合類型，集合元素個數(shù)超過 2000。

以上對 big keys 的判斷標(biāo)準(zhǔn)并不是唯一，只是一個大題的標(biāo)準(zhǔn)。在實際業(yè)務(wù)開發(fā)中，對 big keys 的判斷是需要根據(jù)具體的使用場景做不同的判斷。比如操作某個 key 導(dǎo)致請求響應(yīng)時間變慢，那么這個 key 就可以判定成 big keys。

big keys 是如何產(chǎn)生的

一般來說,big keys 的產(chǎn)生都是由于程序的設(shè)計不當(dāng)，或者對數(shù)據(jù)的規(guī)模沒有一個大體的估算。比如：

• 統(tǒng)計類：例如統(tǒng)計某個網(wǎng)站的訪問用戶信息，網(wǎng)站的訪問量越來越多，這個 key 的元素也會越來越大。變成了 big keys。
• 社交類：例如某個大V微博粉絲量很大,如果不做合理的設(shè)計，也是 big keys。
• 緩存類：一般緩存類的信息訪問都比較頻繁，是將從數(shù)據(jù)庫查詢出來的數(shù)據(jù)序列化到Redis緩存中，這里的緩存如果設(shè)計不當(dāng)，或者為了方便，把所有的數(shù)據(jù)都存在一個 key 下，或者隨著業(yè)務(wù)的擴(kuò)大，對應(yīng)的緩存也增多，也是形成 big keys。

以上幾種類型都是在實際運(yùn)維中遇到的。在開發(fā)中需要根據(jù)預(yù)估的數(shù)據(jù)大小來合理的設(shè)計緩存數(shù)據(jù)。

big keys 的危害

在系統(tǒng)中如果存在 big keys，會導(dǎo)致請求數(shù)據(jù)響應(yīng)變慢、請求超時或者系統(tǒng)不穩(wěn)定。

1、響應(yīng)變慢、超時阻塞

• Redis 是單線程工作的，同一時間只能處理一個請求，操作 big keys 時比較耗時，請求響應(yīng)也變慢。
• 其他請求也處于阻塞狀態(tài)，導(dǎo)致請求超時。
• 除了查詢 big keys 比較耗時，刪除 big keys 也會導(dǎo)致一樣的問題。

2、網(wǎng)絡(luò)擁塞

• 請求單個 big keys 產(chǎn)生的網(wǎng)絡(luò)流量比較大，假設(shè)一個 big keys 為 1MB，客戶端每秒訪問量是 1000，那么每秒產(chǎn)生 1000MB 的流量，普通的千兆網(wǎng)卡承受不了這么大的流量。
• 而且一般會在單機(jī)部署多個Redis實例，一個 big keys 可能也會影響其他實例。

3、內(nèi)存分布不均

• Redis 集群模式中，key根據(jù)不同的hash嘈分配到不同的節(jié)點(diǎn)上，當(dāng)大部分的 big keys 分布在同一個節(jié)點(diǎn)，導(dǎo)致內(nèi)存傾斜在同一個節(jié)點(diǎn)上，內(nèi)存分布不均。
• 在水平擴(kuò)容時，需要以最大容量的節(jié)為準(zhǔn)，浪費(fèi)內(nèi)存。

如何發(fā)現(xiàn) big keys

Redis4.0 后提供了 --bigkeys命令，比如：

./redis-cli --bigkeys

獲取每個數(shù)據(jù)類型最大的 big keys，同時給出每個類型鍵的個數(shù)和平均大小。因為 Redis 是單線程工作的，為了減少對線上請求的影響，執(zhí)行--bigkeys命令需要注意一下幾點(diǎn)：

• 最好在 slave 節(jié)點(diǎn)執(zhí)行，因為 --bigkeys 也是掃描數(shù)據(jù)，會造成其他線程阻塞。
• 使用 --i 參數(shù)，降低掃描的執(zhí)行速度，比如 --i 0.1 表示 100 毫秒執(zhí)行一次。
• 只能統(tǒng)計每個數(shù)據(jù)類型最大的數(shù)據(jù)。

big keys 處理

異步刪除 big keys

找到 big keys 之后，首先需要刪除對應(yīng)的big keys，但是使用 del 命令刪除 big keys 是比較耗時的。Redis4.0 后可以使用 unlink 刪除，和 del 命令相比，unlink 是非阻塞的異步刪除。

非字符串的 big keys，使用 hscan、sscan、zscan 方式漸進(jìn)式刪除，同時要注意防止big keys 過期時間自動刪除問題(例如一個 200 萬的 zset 設(shè)置1小時過期，會觸發(fā)del操作，造成阻塞)。

big key 拆分

字符串類型的數(shù)據(jù)是減少字符串的長度，將一個字符串拆成幾個小的字符串。非字符串的是減少元素數(shù)量。這些都是講一個 key 拆成多個 key，比如：

• 字符串類型的數(shù)據(jù)，根據(jù)數(shù)據(jù)的屬性拆分。比如商品信息，根據(jù)的類別拆分 key。
• 非字符串類型的數(shù)據(jù)，根據(jù)數(shù)據(jù)的屬性拆分，可以按照日期拆分，比如每天登錄人的集合，按照日期拆分，key20220101、key20220102.

如果 big keys 無法避免，那獲取數(shù)據(jù)盡量不要把所有的數(shù)據(jù)都取出來，就使用分段的方式取出數(shù)據(jù)。刪除的方式也類似，分段刪除數(shù)據(jù)。

總結(jié)

• big keys 會造成請求變慢、網(wǎng)絡(luò)阻塞、數(shù)據(jù)丟失的問題。
• big keys 是字符串字節(jié)達(dá)到很大的數(shù)量（比如 5MB），非字符串類型元素類型達(dá)到 1000 個都可以判定成 big keys，具體還需要看具體的場景。
• big keys 的產(chǎn)生可能由于設(shè)計不合理或者對數(shù)據(jù)大小估算錯誤，導(dǎo)致數(shù)據(jù)偏大。
• 解決 big keys 先緊急使用異步刪除 unlink 命令刪除緩存。然后將單個 key 拆分成多個小 key。
• 如果無法避免 big keys，就使用分段查詢的方式查詢數(shù)據(jù)。

要從幾個方面分析：

• big keys 會帶來哪些問題。
• big keys 一般怎么產(chǎn)生的，線上如果產(chǎn)生了big key，線上先怎么緊急處理。
• 有哪些優(yōu)化方案，各自有什么應(yīng)用場景。

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論