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

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

GaussDB(for Redis)

支持大 Key 在線診斷

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

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

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

GaussDB(for Redis)

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

分享兩個真實案例：

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

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

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

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

GaussDB(for Redis)

對大 Key 的承載能力更強

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

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

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

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

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

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

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

3、大 key 導致傾斜，分片內存占用不均勻

開源 Redis 集群中，存儲大 key 會導致內存空間不均勻、消耗不均衡，大 key 所在分片有 OOM 風險。

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

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

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

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

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

審核編輯 黃宇