分布式缓存数据库Redis大KEY问题定位及优化建议是怎样的
这篇文章给大家介绍分布式缓存数据库redis大KEY问题定位及优化建议是怎样的，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
创新互联建站成立于2013年，我们提供高端成都网站建设、网站制作、成都网站设计、网站定制、全网营销推广、小程序开发、微信公众号开发、seo优化排名服务，提供专业营销思路、内容策划、视觉设计、程序开发来完成项目落地，为成都房屋鉴定企业提供源源不断的流量和订单咨询。
如何定位分布式缓存数据库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问题，尽早识别风险。
关于分布式缓存数据库Redis大KEY问题定位及优化建议是怎样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
本文名称：分布式缓存数据库Redis大KEY问题定位及优化建议是怎样的
转载源于：http://shouzuofang.com/article/pgheod.html