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

什么是 big keys

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

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

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

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

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

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

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

big keys 的危害

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

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

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

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

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

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

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

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

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

./redis-cli --bigkeys

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

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

big keys 處理

異步刪除 big keys

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

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

big key 拆分

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

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

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

總結(jié)

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

要從幾個(gè)方面分析：

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

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

最新評(píng)論