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 风险。

 

 

 

GaussDB(for Redis)采用高性能存储池，不会对某个节点分片造成数据量的倾斜，支持大 key 可靠存储，不会导致分片 OOM。

 

 

 

4、Redis 扩容时要搬迁数据，大 key 总引起问题

开源 Redis 扩容时，由于涉及数据跨片搬迁，扩容过程耗时久，存在访问阻塞的风险。如图所示，因此开源 Redis 在有大 key 的情况下，扩容必须谨慎！

 

 

 

GaussDB(for Redis)支持秒级无感扩容，不论扩容量，还是扩 CPU，都不需要搬迁数据，因此也不受大 Key 影响，运维体验极佳。

 

 

 

本文介绍了 GaussDB(for Redis)的大 Key 诊断、大 Key 预警特性，以及在大 Key 场景下如何解决开源 Redis 的稳定性痛点，为客户提供了高效可靠的大 Key 解决方案。未来，GaussDB(for Redis)将持续致力于开发更多好用的企业级特性，帮助客户轻松运维，高效开发。

 

审核编辑 黄宇