本文分享自华为云社区《华为云GaussDB(for Redis)揭秘第31期：大key治理》，作者： 高斯Redis官方博客。
从DBA的视角看，大Key无疑是引起Redis线上问题的常见原因。为了解决大Key隐患，业务首先要遵守合理的开发规范，减少大Key的产生和访问依赖。但有时大Key是在程序运行过程中悄悄产生的，让人防不胜防。因此，一款可随时在线诊断，且能主动预警，防患于未然的Redis服务产品显得尤为重要。
GaussDB(for Redis)采用计算、存储分离的高可靠架构，每个计算节点上都部署有后台任务。GaussDB(for Redis)通过后台任务持续检测分析存储池中的大key情况，用户执行命令时直接取结果，不会影响线上业务，跟业界阻塞式全量扫描方式相比，更安全。
用户执行bigkeys命令后，将直接从节点上获取“答案”，不用全库扫描引起不必要的性能影响。
此外，GaussDB(for Redis)支持用户自定义大key标准，比如大于1MB的string、大于10000个元素的hash类型等。该功能一经推出，收获了很多客户和DBA小伙伴的认可及点赞。
分享两个真实案例：
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案发现场”，将风险扼杀于萌芽状态。
即使在大Key存在的一些业务场景，GaussDB(for Redis)的表现也是远优于开源Redis的。下面将介绍大Key经常引起的一些问题：
在开源Redis中，大key容易引起CPU占用100%，使生产业务受损，引起线上问题。这是因为开源Redis本身就是单线程，尤其在这种比较脆弱的架构下使用大key，更容易引起线程阻塞，从而影响整个实例。
GaussDB(for Redis)的多线程架构天然就对大key更友好，不会有这个问题困扰。即使单个线程被个别大Key影响，整个GaussDB(for Redis)实例包含数十、上百个线程，整体业务基本都不会受到干扰。
目前市面上有一些开源Redis是基于一个大的容器混合部署很多租户的Redis进程，但在这种架构下，为了避免一个客户的Redis影响其他客户，往往会对客户的Redis进程进行流量控制，当某个客户业务中对大key有较为频繁的操作时，很容易触发给客户设定的该租户的带宽阈值并触发流控，从而导致线上业务受损。
相比之下，GaussDB(for Redis)的每个分片都是一个独立的容器，是客户的独享资源，更可靠，连接数、带宽等资源不设主动流控，尤其是节点带宽资源的“天花板”非常高。
开源Redis集群中，存储大key会导致内存空间不均匀、消耗不均衡，大key所在分片有OOM风险。
GaussDB(for Redis)采用高性能存储池，不会对某个节点分片造成数据量的倾斜，支持大key可靠存储，不会导致分片OOM。
开源Redis扩容时，由于涉及数据跨片搬迁，扩容过程耗时久，存在访问阻塞的风险。如图所示，因此开源Redis在有大key的情况下，扩容必须谨慎！
GaussDB(for Redis)支持秒级无感扩容，不论扩容量，还是扩CPU，都不需要搬迁数据，因此也不受大Key影响，运维体验极佳。
本文介绍了GaussDB(for Redis)的大Key诊断、大Key预警特性，以及在大Key场景下如何解决开源Redis的稳定性痛点，为客户提供了高效可靠的大Key解决方案。未来，GaussDB(for Redis)将持续致力于开发更多好用的企业级特性，帮助客户轻松运维，高效开发。
华为云数据库GaussDB(for Redis)团队
yuwenlong4@huawei.com
bbs.huaweicloud.com/blogs/248875
GaussDB(for Redis)提供了完备的大Key解决方案，支持大Key在线诊断、监控预警、承载力强等能力，弥补了开源Redis在大key问题上的不足，让DBA如虎添翼。