分布式缓存数据库Redis大KEY问题定位及优化建议是怎样的

49次阅读
没有评论

共计 2344 个字符,预计需要花费 6 分钟才能阅读完成。

这篇文章给大家介绍分布式缓存数据库 Redis 大 KEY 问题定位及优化建议是怎样的,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。

如何定位分布式缓存数据库 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%,结果如下图所示:

分布式缓存数据库 Redis 大 KEY 问题定位及优化建议是怎样的

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

分布式缓存数据库 Redis 大 KEY 问题定位及优化建议是怎样的

【优化及建议】

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

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

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

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

关于分布式缓存数据库 Redis 大 KEY 问题定位及优化建议是怎样的就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-16发表,共计2344字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)