GaussDB(for Redis)特性揭秘：大key治理

风晓 2024-01-12 14:05:33  52786 赞同 0 反对 0

分类：资源标签：国产数据库

GaussDB(for Redis)特性揭秘：大key治理

从DBA的视角看，大Key无疑是引起Redis线上问题的常见原因。为了解决大Key隐患，业务首先要遵守合理的开发规范，减少大Key的产生和访问依赖。但有时大Key是在程序运行过程中悄悄产生的，让人防不胜防。因此，一款可随时在线诊断，且能主动预警，防患于未然的Redis服务产品显得尤为重要。

作为由华为云精心打造的企业级Redis，GaussDB(for Redis)提供了完备的大Key解决方案，支持大Key在线诊断、监控预警、承载力强等能力，让DBA如虎添翼。

GaussDB(for Redis)

支持大Key在线诊断

GaussDB(for Redis)采用计算、存储分离的高可靠架构，每个计算节点上都部署有后台任务。GaussDB(for Redis)通过后台任务持续检测分析存储池中的大key情况，用户执行命令时直接取结果，不会影响线上业务，跟业界阻塞式全量扫描方式相比，更安全。

用户执行bigkeys命令后，将直接从节点上获取“答案”，不用全库扫描引起不必要的性能影响。

此外，GaussDB(for Redis)支持用户自定义大key标准，比如大于1MB的string、大于10000个元素的hash类型等。该功能一经推出，收获了很多客户和DBA小伙伴的认可及点赞。

GaussDB(for Redis)

支持大key监控预警

分享两个真实案例：

1、业务周期性执行“lrange 0 -1”获取list key的所有元素。但由于程序bug，业务也同时在长期、缓慢地向这个key中持续追加，导致key越来越长。直到线上业务出问题，几经波折，才发现了这个危险的大Key。

2、业务长期稳定运行，有一天有新组件上线，线上业务开始不断超时。几经排查，发现新组件对Redis执行hmset f1 v1 f2 v2……，一条写入命令携带了长达2万个参数，严重影响了生产业务。

从DBA的角度，这类问题需要一个“大Key侦探”时刻盯防，一旦有对大Key的高危操作，立刻主动预警。

GaussDB(for Redis)设计了10+监控指标，提供“大Key侦探”的能力，例如：单个请求回包的最大元素个数（识别lrange 0 -1操作大key引起阻塞的场景）、单个请求携带的最大参数个数（识别hmset上万元素批导引起阻塞的场景）……DBA只需要根据多年经验，将这类指标订阅告警，即可在第一时间“抓住大Key案发现场”，将风险扼杀于萌芽状态。

GaussDB(for Redis)

对大Key的承载能力更强

即使在大Key存在的一些业务场景，GaussDB(for Redis)的表现也是远优于开源Redis的。下面将介绍大Key经常引起的一些问题：

1、大key引发了CPU 100%，阻塞生产业务

在开源Redis中，大key容易引起CPU占用100%，使生产业务受损，引起线上问题。这是因为开源Redis本身就是单线程，尤其在这种比较脆弱的架构下使用大key，更容易引起线程阻塞，从而影响整个实例。

GaussDB(for Redis)的多线程架构天然就对大key更友好，不会有这个问题困扰。即使单个线程被个别大Key影响，整个GaussDB(for Redis)实例包含数十、上百个线程，整体业务基本都不会受到干扰。

2、大key因个别分片带宽高，被Redis频繁“流控”

目前市面上有一些开源Redis是基于一个大的容器混合部署很多租户的Redis进程，但在这种架构下，为了避免一个客户的Redis影响其他客户，往往会对客户的Redis进程进行流量控制，当某个客户业务中对大key有较为频繁的操作时，很容易触发给客户设定的该租户的带宽阈值并触发流控，从而导致线上业务受损。

相比之下，GaussDB(for Redis)的每个分片都是一个独立的容器，是客户的独享资源，更可靠，连接数、带宽等资源不设主动流控，尤其是节点带宽资源的“天花板”非常高。

3、大key导致倾斜，分片内存占用不均匀

开源Redis集群中，存储大key会导致内存空间不均匀、消耗不均衡，大key所在分片有OOM风险。