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

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

GaussDB(for Redis)

支持大 Key 在線(xiàn)診斷

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

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

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

GaussDB(for Redis)

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

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

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

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

從 DBA 的角度，這類(lèi)問(wèn)題需要一個(gè)“大 Key 偵探”時(shí)刻盯防，一旦有對(duì)大 Key 的高危操作，立刻主動(dòng)預(yù)警。

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

GaussDB(for Redis)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

審核編輯 黃宇