Redis 的 BigKey、HotKey 又引发了线上事故！( 四 ) _Redis

如何解决呢？
大概的解决流程，如下：

进入工单找到失败的实例，使用失败实例的 slave 节点，在 Daas 平台的“工具集-操作项管理”进行 Bigkey 分析。

文章插图

经过分析找出了 hash 类型的 Bigkey 有 8421874 个 fields，正是这个 Bigkey 导致迁移时间太长，超过了迁移时间限制，导致工单失败了。

文章插图
3.和业务沟通，这些 key 是记录用户访问系统的某个功能模块的 ip 地址的，访问该功能模块的所有 ip 都会记录到给 key 里面，随着时间的积累，这个 key 变的越来越大。同样是采用拆分的方式进行优化，可以考虑按照时间日期维度来拆分，就是一段时间段的访问 ip 记录到一个 key 中。
4.Bigkey 优化后，扩容的工单可以重试，完成集群扩容操作。
生产上如何进行Bigkey 的发现

首先需要重源头治理，防止 Bigkey 的产生；
其次是需要能够及时的发现，发现后及时处理。

分析 Bigkey 的方法不少，这里介绍两种比较常用的方法，也是 Daas 平台分析 Bigkey 使用的两种方式，分别是 Bigkeys 命令分析法、RDB 文件分析法。
1.Bigkeys 命令分析Redis4.0 及以上版本提供了--Bigkeys 命令，可以分析出实例中每种数据结构的 top 1 的 Bigkey，同时给出了每种数据类型的键值个数以及平均大小。
执行--Bigkeys 命令时候需要注意以下几点：

建议在 slave 节点执行，因为--Bigkeys 也是通过 scan 完成的，可能会对节点造成阻塞。
建议在节点本机执行，这样可以减少网络开销。
如果没有从节点，可以使用--i 参数，例如(--i 0.1 代表 100 毫秒执行一次) 。
--Bigkeys 只能计算每种数据结构的 top1，如果有些数据结构有比较多的 Bigkey，是查找不出来的。

Daas 平台集成了基于原生--Bigkeys 代码实现的查询 Bigkey 的方式，这个方式的缺点是只能计算每种数据结构的 top1，如果有些数据结构有比较多的 Bigkey，是查找不出来的。该方式相对比较安全，已经开放出来给业务开发同学使用。
2. RDB 文件分析借助开源的工具，比如 rdb-tools，分析 Redis 实例的 RDB 文件，找出其中的 Bigkey，这种方式需要生成 RDB 文件，需要注意以下几点：

建议在 slave 节点执行，因为生成 RDB 文件会影响节点性能。
需要生成 RDB 文件，会影响节点性能，虽然在 slave 节点执行，但是也是有可能造成主从中断，进而影响到 master 节点。

Daas 平台集成了基于 RDB 文件分析代码实现的查询 Bigkey 的方式，可以根据实际需求自定义填写 N，分析的 top N 个 Bigkey 。该方式相对有一定风险，只有 DBA 有权限执行分析。
3.Bigkey 巡检通过巡检，可以暴露出隐患，提前解决，避免故障的发生，进行全网 Bigkey 的巡检，是避免 Bigkey 故障的比较好的方法。
由于全网 Redis 实例数量非常大，分析的速度比较慢，使用当前的分析方法很难完成。
为了解决这个问题，存储研发组分布式数据库同学计划开发一个高效的 RDB 解析工具，然后通过大规模解析 RDB 文件来分析 Bigkey，可以提高分析速度，实现 Bigkey 的巡检。
生产上 Bigkey 处理优化1. Bigkey 拆分优化 Bigkey 的原则就是 string 减少字符串长度，list、hash、set、zset 等减少元素数量。当我们知道哪些 key 是 Bigkey 时，可以把单个 key 拆分成多个 key，比如以下拆分方式可以参考。

big list：list1、list2、...listN
big hash：可以做二次的 hash，例如 hash%100
按照日期拆分多个：key20220310、key20220311、key202203212

2. Bigkey 分析工具优化我们全网 Redis 集群有 2200 以上，实例数量达到 4.5 万以上，有的比较大的集群的实例数量达到了 1000 以上，前面提到的两种 Bigkey 分析工具还都是实例维度分析，对于实例数量比较大的集群，进行全集群分析也是比较耗时的，为了提高分析效率，从以下几个方面进行优化：