揭秘华为云GaussDB(for Redis)丨大key治理
本文分享自华为云社区《华为云GaussDB(for Redis)揭秘第31期:大key治理》,作者: 高斯Redis官方博客。
从DBA的视角看,大Key无疑是引起Redis线上问题的常见原因。为了解决大Key隐患,业务首先要遵守合理的开发规范,减少大Key的产生和访问依赖。但有时大Key是在程序运行过程中悄悄产生的,让人防不胜防。因此,一款可随时在线诊断,且能主动预警,防患于未然的Redis服务产品显得尤为重要。
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)将持续致力于开发更多好用的企业级特性,帮助客户轻松运维,高效开发。
附录
- 本文作者:
华为云数据库GaussDB(for Redis)团队
- 杭州/西安/深圳简历投递:
yuwenlong4@huawei.com
- 更多产品信息,欢迎访问官方博客:
bbs.huaweicloud.com/blogs/248875
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
smart-flow v1.1.3 发布 优化使用体验&适配 Nacos
1、smart-flow 简介 smart-flow 是一个轻量、灵活的业务流程编排框架,支持业务流程中常见的条件分支控制、子流程、业务组件异步和降级等功能。同时 smart-flow 也是一款具备可观测性的流程编排框架,流程结构拓扑、执行路径跟踪、链路分析等功能能帮助您洞察整个业务流程和执行。 smartboot 开源组织,一个容易被误认为是在 “重复造轮子” 的低调组织。曾获得2020 年度 OSC 中国开源项目「优秀 Gitee 组织 」荣誉。 该组织内的明星项目包括: smart-socket 历时 5 年精炼出 2 千多行代码,轻松实现百万级长连接的 AIO 通信框架。 smart-http 基于 smart-socket 实现的 HTTP/1.1 web 服务。 smart-servlet 基于 smart-http 实现的 Servlet 3.1 容器服务。 smart-mqtt 基于 smart-socket 实现的 MQTT 3.1.1/5.0 Broker&Client 服务。 smart-flow 一款具备可观测性的轻量级业务编排框架。 组织地址:http...
- 下一篇
基于卷积神经网络的MAE自监督方法
本文分享自华为云社区《基于卷积神经网络的MAE自监督方法》,作者: Hint 。 图像自监督预训练算法是近年来的重要研究方向,MAE是其中基于ViT实现的代表性方法,学习到了鲁棒的视觉特征。MAE全称是Masked Autoencoders,是由何凯明提出的自监督预训练方法,借鉴了BERT的预训练任务,将输入图片的patch以较大的比例进行mask,并通过非对称的ViT编码解码器结构,进行masked patches的重建任务。该方法在性能上超过了以往的对比学习方法,如MoCo系列等。然而ViT的结构复杂,计算量庞大,基于CNN的类MAE方法具有极高研究价值,但受限于CNN的结构特性,常规的MAE方式无法直接在CNN上应用。本文介绍ICLR2023的方法Spark[1],实现了基于CNN的MAE。 如上图所示,对于一个masked的输入图片,对ViT输入和CNN的输入计算统计直方图,ViT的直方图是和未mask的图片分布一致的,而CNN的直方图发生了很大变化。这是由于ViT结构天然适合处理变长、不规则的输入,且不同的输入之间不会重叠计算。CNN的滑窗操作和规则的卷积核形状,导致模型会严...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- 设置Eclipse缩进为4个空格,增强代码规范
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2全家桶,快速入门学习开发网站教程
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS7设置SWAP分区,小内存服务器的救世主