共计 2122 个字符，预计需要花费 6 分钟才能阅读完成。
摘要： 如何定位分布式缓存数据库 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.c…
② 命令剖析：应用 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/weiyanwei4…。具体步骤如下：
编译办法：
yum install git go -y
mkdir /home/gocode/
cd /home/gocode/
git clone https://github.com/weiyanwei4…
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/…
四、解决方案
导致本次 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 问题，尽早辨认危险。
点击关注，第一工夫理解华为云陈腐技术~