從 DBA 的視角看，大 Key 無疑是引起 Redis 線上問題的常見原因。為了解決大 Key 隱患，業(yè)務(wù)首先要遵守合理的開發(fā)規(guī)范，減少大 Key 的產(chǎn)生和訪問依賴。但有時大 Key 是在程序運(yùn)行過程中悄悄產(chǎn)生的，讓人防不勝防。因此，一款可隨時在線診斷，且能主動預(yù)警，防患于未然的 Redis 服務(wù)產(chǎn)品顯得尤為重要。

作為由華為云精心打造的企業(yè)級 Redis，GaussDB(for Redis)提供了完備的大 Key 解決方案，支持大 Key 在線診斷、監(jiān)控預(yù)警、承載力強(qiáng)等能力，讓 DBA 如虎添翼。

GaussDB(for Redis)

支持大 Key 在線診斷

GaussDB(for Redis)采用計(jì)算、存儲分離的高可靠架構(gòu)，每個計(jì)算節(jié)點(diǎn)上都部署有后臺任務(wù)。GaussDB(for Redis)通過后臺任務(wù)持續(xù)檢測分析存儲池中的大 key 情況，用戶執(zhí)行命令時直接取結(jié)果，不會影響線上業(yè)務(wù)，跟業(yè)界阻塞式全量掃描方式相比，更安全。

用戶執(zhí)行 bigkeys 命令后，將直接從節(jié)點(diǎn)上獲取“答案”，不用全庫掃描引起不必要的性能影響。

此外，GaussDB(for Redis)支持用戶自定義大 key 標(biāo)準(zhǔn)，比如大于 1MB 的 string、大于 10000 個元素的 hash 類型等。該功能一經(jīng)推出，收獲了很多客戶和 DBA 小伙伴的認(rèn)可及點(diǎn)贊。

GaussDB(for Redis)

支持大 key 監(jiān)控預(yù)警

分享兩個真實(shí)案例：

1、業(yè)務(wù)周期性執(zhí)行“l(fā)range 0 -1”獲取 list key 的所有元素。但由于程序 bug，業(yè)務(wù)也同時在長期、緩慢地向這個 key 中持續(xù)追加，導(dǎo)致 key 越來越長。直到線上業(yè)務(wù)出問題，幾經(jīng)波折，才發(fā)現(xiàn)了這個危險的大 Key。

2、業(yè)務(wù)長期穩(wěn)定運(yùn)行，有一天有新組件上線，線上業(yè)務(wù)開始不斷超時。幾經(jīng)排查，發(fā)現(xiàn)新組件對 Redis 執(zhí)行 hmset f1 v1 f2 v2……，一條寫入命令攜帶了長達(dá) 2 萬個參數(shù)，嚴(yán)重影響了生產(chǎn)業(yè)務(wù)。

從 DBA 的角度，這類問題需要一個“大 Key 偵探”時刻盯防，一旦有對大 Key 的高危操作，立刻主動預(yù)警。

GaussDB(for Redis)設(shè)計(jì)了 10+監(jiān)控指標(biāo)，提供“大 Key 偵探”的能力，例如：單個請求回包的最大元素個數(shù)（識別 lrange 0 -1 操作大 key 引起阻塞的場景）、單個請求攜帶的最大參數(shù)個數(shù)（識別 hmset 上萬元素批導(dǎo)引起阻塞的場景）……DBA 只需要根據(jù)多年經(jīng)驗(yàn)，將這類指標(biāo)訂閱告警，即可在第一時間“抓住大 Key 案發(fā)現(xiàn)場”，將風(fēng)險扼殺于萌芽狀態(tài)。

GaussDB(for Redis)

對大 Key 的承載能力更強(qiáng)

即使在大 Key 存在的一些業(yè)務(wù)場景，GaussDB(for Redis)的表現(xiàn)也是遠(yuǎn)優(yōu)于開源 Redis 的。下面將介紹大 Key 經(jīng)常引起的一些問題：

1、大 key 引發(fā)了 CPU 100%，阻塞生產(chǎn)業(yè)務(wù)

在開源 Redis 中，大 key 容易引起 CPU 占用 100%，使生產(chǎn)業(yè)務(wù)受損，引起線上問題。這是因?yàn)殚_源 Redis 本身就是單線程，尤其在這種比較脆弱的架構(gòu)下使用大 key，更容易引起線程阻塞，從而影響整個實(shí)例。

GaussDB(for Redis)的多線程架構(gòu)天然就對大 key 更友好，不會有這個問題困擾。即使單個線程被個別大 Key 影響，整個 GaussDB(for Redis)實(shí)例包含數(shù)十、上百個線程，整體業(yè)務(wù)基本都不會受到干擾。

2、大 key 因個別分片帶寬高，被 Redis 頻繁“流控”

目前市面上有一些開源 Redis 是基于一個大的容器混合部署很多租戶的 Redis 進(jìn)程，但在這種架構(gòu)下，為了避免一個客戶的 Redis 影響其他客戶，往往會對客戶的 Redis 進(jìn)程進(jìn)行流量控制，當(dāng)某個客戶業(yè)務(wù)中對大 key 有較為頻繁的操作時，很容易觸發(fā)給客戶設(shè)定的該租戶的帶寬閾值并觸發(fā)流控，從而導(dǎo)致線上業(yè)務(wù)受損。

相比之下，GaussDB(for Redis)的每個分片都是一個獨(dú)立的容器，是客戶的獨(dú)享資源，更可靠，連接數(shù)、帶寬等資源不設(shè)主動流控，尤其是節(jié)點(diǎn)帶寬資源的“天花板”非常高。

3、大 key 導(dǎo)致傾斜，分片內(nèi)存占用不均勻

開源 Redis 集群中，存儲大 key 會導(dǎo)致內(nèi)存空間不均勻、消耗不均衡，大 key 所在分片有 OOM 風(fēng)險。

GaussDB(for Redis)采用高性能存儲池，不會對某個節(jié)點(diǎn)分片造成數(shù)據(jù)量的傾斜，支持大 key 可靠存儲，不會導(dǎo)致分片 OOM。

4、Redis 擴(kuò)容時要搬遷數(shù)據(jù)，大 key 總引起問題

開源 Redis 擴(kuò)容時，由于涉及數(shù)據(jù)跨片搬遷，擴(kuò)容過程耗時久，存在訪問阻塞的風(fēng)險。如圖所示，因此開源 Redis 在有大 key 的情況下，擴(kuò)容必須謹(jǐn)慎！

GaussDB(for Redis)支持秒級無感擴(kuò)容，不論擴(kuò)容量，還是擴(kuò) CPU，都不需要搬遷數(shù)據(jù)，因此也不受大 Key 影響，運(yùn)維體驗(yàn)極佳。

本文介紹了 GaussDB(for Redis)的大 Key 診斷、大 Key 預(yù)警特性，以及在大 Key 場景下如何解決開源 Redis 的穩(wěn)定性痛點(diǎn)，為客戶提供了高效可靠的大 Key 解決方案。未來，GaussDB(for Redis)將持續(xù)致力于開發(fā)更多好用的企業(yè)級特性，幫助客戶輕松運(yùn)維，高效開發(fā)。

審核編輯 黃宇