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

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

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



GaussDB(for Redis)

支持大Key在线诊断


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


3b0f0d9527f01df07ab64df4249816b1.jpeg


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

4c0c53101ba19b69e8fd0d46499264bb.jpeg


此外,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风险。


d59f2bd11ed1b036ab05c863d2b335d4.jpeg


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


7cb564ae8539dcc00e17c269d73dc1e1.jpeg


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

9925e83cea9a2f9bb1e633451cc0ba5f.jpeg


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


e0029496060d70a5546b19ef74035a91.jpeg



075ea7ce4e5a631dd80e57730cb5e86f.jpeg


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

附录
  • 本文作者

华为云GaussDB(for Redis)团队

  • 杭州/西安/深圳简历投递

yuwenlong4@huawei.com

  • 更多产品信息,欢迎访问Redis官方博客

bbs.huaweicloud.com/blogs/248875

2c8d80f2d26d8c126c9445bd6a2f12a2.jpeg


戳“阅读原文”,了解更多

  • 6
    点赞
  • 19
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值