写点什么

技术解读丨分布式缓存数据库 Redis 大 KEY 问题定位及优化建议

发布于: 2020 年 10 月 14 日

摘要:如何定位分布式缓存数据库Redis大KEY问题,实操案例带你掌握优化方法。



【背景】



访问Redis 5.0 cluster集群出现OOM报错,报错信息为(error) OOM command not allowed when used memory > ‘maxmemory’,部分ECS应用程序无法向数据库写入,影响服务的正常使用。执行set t2 s2时,数据库报错OOM,如下图:





【拓扑】





环境信息:



Redis 5.0 cluster集群 4G内存



DCS网段:192.168.1.0/24



分片1:master 192.168.1.12 slave 192.168.1.37



分片2:master 192.168.1.10 slave 192.168.1.69



分片3:master 192.168.1.26 slave 192.168.1.134



【分析思路】





【详细步骤】



一、查看监控



查看Redis实例监控,显示Redis集群内存占用46.97%,无明显异常,结果如下图所示:





查看节点的内存监控。其中分片2中master节点192.168.1.10内存使用率达到100%,其余两个分片分内存使用率均在20%左右,结果如下图所示:





二、确认异常分片信息



通过上述监控信息可得知,该redis集群中的分片2中内存使用率达100%。有且仅有该分片内存异常。



三、大KEY分析



在线分析



① 工具分析:使用华为云管理控制台缓存分析-大Key分析工具。执行完成后,查看信息即可。结果如下图所示:(string类型保存top20,list/set/zset/hash类型保存top80)



具体使用方法参考以下链接:https://support.huaweicloud.com/usermanual-dcs/dcs-ug-190808001.html





② 命令分析:使用redis-cli -h IP -p port –bigkeys命令,该工具会列出各个类型数据中大Key中的最大的那个key的信息。结果如下图所示:





如上图所示,可以得出该环境中string类型的大key为“nc_filed/_pk”,大小为13283byte,list、set、hash、zset类型的数据未发现大key。



离线方式



离线分析需要使用专门的rdb_bigkeys分析工具,对rdb文件进行分析。工具地址: https://github.com/weiyanwei412/rdb_bigkeys。具体步骤如下:



编译方法:



# yum install git go -y



# mkdir /home/gocode/



# cd /home/gocode/



# git clone https://github.com/weiyanwei412/rdb_bigkeys.git



# cd rdb_bigkeys



# go build



执行完成生成可执行文件rdb_bigkeys。

使用方法:



./rdb_bigkeys -bytes 1024 -file bigkeys.csv -sorted -threads 4 /home/redis/dump.rdb



参数说明:



-bytes 1024:筛选大于1024字节的key



-file bigkeys.csv:将结果保存到bigkeys.csv文件



-sorted:从大到小进行排序



-threads:使用的线程个数



/home/redis/dump.rdb:实际的rdb文件路径



生成文件样式如下所示:





每列分别为数据库编号,key类型,key名,key大小,元素数量,最大值元素名,元素大小,key过期时间。文档链接:https://www.cnblogs.com/yqzc/p/12425533.html



四、解决方案



导致本次OOM问题的根因为大KEY导致数据大小分布不均匀,某一个分片内存达到maxmemory,在进行数据写入的过程中,如果调度到该分片,则会产生OOM问题。将该分片的rdb文件导出一份,以便于后期针对大key做对应的优化。



临时方案:



为尽快回复业务,删除上有步骤中查询到的大KEY,执行操作如下:(非字符串的bigkey,不要使用 del 删除,使用 hscan、sscan、zscan 方式渐进式删除)





长期方案:



通过对大KEY进行拆分,将一个大的KEY拆分为多个小的KEY, 变成value1,value2… valueN,打散分不到不同的分片中,避免因为数据倾斜导致的数据分布不均。





其他的类型的数据也可以按照相同的方式进行拆分重组,从而避免大KEY带来的影响。



五、 结果验证



查看分片监控,192.168.1.10内存使用率下降到24%,结果如下图所示:





执行set t2 s2,返回正常,登录集群,执行get命令,正常返回数据信息。结果如下所示,至此业务恢复正常。





【优化及建议】



1) 配置节点级别的内存利用率监控指标的告警。如果某个节点存在大key,这个节点比其他节点内存使用率高很多,会触发告警,便于用户发现潜在的大key。



2) 配置节点级别的入网最大带宽、出网最大带宽、CPU利用率监控指标的告警。如果某个节点存在热key,这个节点的带宽占用、CPU利用率都比其他节点高,该节点会容易触发告警,便于用户发现潜在热key。



3) string类型控制在10KB以内,hash、list、set、zset元素尽量不超过5000。



4) 定期通过大key、热key分析工具检查集群中是否存在大key问题,尽早识别风险。



点击关注,第一时间了解华为云新鲜技术~



发布于: 2020 年 10 月 14 日阅读数: 51
用户头像

提供全面深入的云计算技术干货 2020.07.14 加入

华为云开发者社区,提供全面深入的云计算前景分析、丰富的技术干货、程序样例,分享华为云前沿资讯动态,方便开发者快速成长与发展,欢迎提问、互动,多方位了解云计算! 传送门:https://bbs.huaweicloud.com/

评论

发布
暂无评论
技术解读丨分布式缓存数据库Redis大KEY问题定位及优化建议