共计 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%，结果如下图所示：
执行 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 问题定位及优化建议是怎样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
