在 Redis 运维过程中，由于 Bigkey 的存在，会影响业务程序的响应速度，严重的还会造成可用性损失，DBA 也一直和业务开发方强调 Bigkey 的规避方法以及危害。
一、背景
在 Redis 运维过程中，由于 Bigkey 的存在，会影响业务程序的响应速度，严重的还会造成可用性损失，DBA 也一直和业务开发方强调 Bigkey 的规避方法以及危害，但是 Bigkey 一直没有完全避免。全网 Redis 集群有 2200 个以上，实例数量达到 4.5 万以上，在当前阶段进行一次全网 Bigkey 检查，估计需要以年为时间单位，非常耗时。我们需要新的思路去解决 Bigkey 问题。
二、Bigkey 介绍
2.1、什么是 Bigkey
在 Redis 中，一个字符串类型最大可以到 512MB，一个二级数据结构（比如 hash、list、set、zset 等）可以存储大约 40 亿个 (2^32-1) 个元素，但实际上不会达到这么大的值，一般情况下如果达到下面的情况，就可以认为它是 B
igkey 了。
【字符串类型】： 单个 string 类型的 value 值超过 1MB，就可以认为是 Bigkey。
【非字符串类型】：哈希、列表、集合、有序集合等， 它们的元素个数超过 2000 个，就可以认为是 Bigkey。
2.2 Bigkey 是怎么产生的
我们遇到的 Bigkey 一般都是由于程序设计不当或者对于数据规模预料不清楚造成的，比如以下的情况。
【统计】：遇到一个统计类的 key，是记录某网站的访问用户的 IP，随着时间的推移，网站访问的用户越来越多，这个 key 的元素数量也会越来越大，形成 Bigkey。
【缓存】： 缓存类 key 一般是这样的逻辑，将数据从数据库查询出来序列化放到 Redis 里，如果业务程序从 Redis 没有访问到，就会查询数据库并将查询到的数据追加到 Redis 缓存中，短时间内会缓存大量的数据到 Redis 的 key 中，形成 Bigkey。
【队列】：把 Redis 当做队列使用，处理任务，如果消费出现不及时情况，将导致队列越来越大，形成 Bigkey。
这三种情况，都是我们实际运维中遇到的，需要谨慎使用，合理优化。
2.3 Bigkey 的危害
我们在运维中，遇到 Bigkey 的情况下，会导致一些问题，会触发监控报警，严重的还会影响 Redis 实例可用性，进而影响业务可用性，在需要水平扩容时候，可能导致水平扩容失败。
2.3.1 内存空间不均匀
内存空间不均匀会不利于集群对内存的统一管理，有数据丢失风险。下图中的三个节点是同属于一个集群，它们的 key 的数量比较接近，但内存容量相差比较多，存在 Bigkey 的实例占用的内存多了 4G 以上了。
可以使用使用 Daas 平台 “工具集 - 操作项管理”，选择对应的 slave 实例执行分析，找出具体的 Bigkey。
2.3.2 超时阻塞
Redis 是单线程工作的，通俗点讲就是同一时间只能处理一个 Redis 的访问命令，操作 Bigkey 的命令通常比较耗时，这段时间 Redis 不能处理其他命令，其他命令只能阻塞等待，这样会造成客户端阻塞，导致客户端访问超时，更严重的会造成 master-slave 的故障切换。造成阻塞的操作不仅仅是业务程序的访问，还有 key 的自动过期的删除、del 删除命令，对于 Bigkey，这些操作也需要谨慎使用。
超时阻塞案例
我们遇到一个这样超时阻塞的案例，业务方反映程序访问 Redis 集群出现超时现象，hkeys 访问 Redis 的平均响应时间在 200 毫秒左右，最大响应时间达到了 500 毫秒以上，如下图。
hkeys 是获取所有哈希表中的字段的命令，分析应该是集群中某些实例存在 hash 类型的 Bigkey，导致 hkeys 命令执行时间过长，发生了阻塞现象。
1. 使用 Daas 平台 “服务监控 - 数据库实例监控”，选择 master 节点，选择 Redis 响应时间监控指标 “redis.instance.latency.max”，如下图所示，从监控图中我们可以看到
（1）正常情况下，该实例的响应时间在 0.1 毫秒左右。
（2）监控指标上面有很多突刺，该实例的响应时间到了 70 毫秒左右，最大到了 100 毫秒左右，这种情况就是该实例会有 100 毫秒都在处理 Bigkey 的访问命令，不能处理其他命令。
通过查看监控指标，验证了我们分析是正确的，是这些监控指标的突刺造成了 hkeys 命令的响应时间比较大，我们找到了具体的 master 实例，然后使用 master 实例的 slave 去分析下 Bigkey 情况。
2. 使用 Daas 平台 “工具集 - 操作项管理”，选择 slave 实例执行分析，分析结果如下图，有一个 hash 类型 key 有 12102218 个 fields。
3. 和业务沟通，这个 Bigkey 是连续存放了 30 天的业务数据了，建议根据二次 hash 方式拆分成多个 key，也可把 30 天的数据根据分钟级别拆分成多个 key，把每个 key 的元素数量控制在 5000 以内，目前业务正在排期优化中。优化后，监控指标的响应时间的突刺就会消失了。
2.3.3 网络阻塞
Bigkey 的 value 比较大，也意味着每次获取要产生的网络流量较大，假设一个 Bigkey 为 10MB，客户端每秒访问量为 100，那么每秒产生 1000MB 的流量，对于普通的千兆网卡 (按照字节算是 128MB/s) 的服务器来说简直是灭顶之灾。而且我们现在的 Redis 服务器是采用单机多实例的方式来部署 Redis 实例的，也就是说一个 Bigkey 可能会对同一个服务器上的其他 Redis 集群实例造成影响，影响到其他的业务。
2.3.4 迁移困难
我们在运维中经常做的变更操作是水平扩容，就是增加 Redis 集群的节点数量来达到扩容的目的，这个水平扩容操作就会涉及到 key 的迁移，把原实例上的 key 迁移到新扩容的实例上。当要对 key 进行迁移时，是通过 migrate 命令来完成的，migrate 实际上是通过 dump + restore + del 三个命令组合成原子命令完成，它在执行的时候会阻塞进行迁移的两个实例，直到以下任意结果发生才会释放：迁移成功，迁移失败，等待超时。如果 key 的迁移过程中遇到 Bigkey，会长时间阻塞进行迁移的两个实例，可能造成客户端阻塞，导致客户端访问超时；也可能迁移时间太长，造成迁移超时导致迁移失败，水平扩容失败。
迁移失败案例
我们也遇到过一些因为 Bigkey 扩容迁移失败的案例，如下图所示，是一个 Redis 集群水平扩容的工单，需要进行 key 的迁移，当工单执行到 60% 的时候，迁移失败了。
1. 进入工单找到失败的实例，使用失败实例的 slave 节点，在 Daas 平台的 “工具集 - 操作项管理” 进行 Bigkey 分析。
2. 经过分析找出了 hash 类型的 Bigkey 有 8421874 个 fields，正是这个 Bigkey 导致迁移时间太长，超过了迁移时间限制，导致工单失败了。
3. 和业务沟通，这些 key 是记录用户访问系统的某个功能模块的 ip 地址的，访问该功能模块的所有 ip 都会记录到给 key 里面，随着时间的积累，这个 key 变的越来越大。同样是采用拆分的方式进行优化，可以考虑按照时间日期维度来拆分，就是一段时间段的访问 ip 记录到一个 key 中。
4.Bigkey 优化后，扩容的工单可以重试，完成集群扩容操作。
三、Bigkey 的发现
Bigkey 首先需要重源头治理，防止 Bigkey 的产生；其次是需要能够及时的发现，发现后及时处理。分析 Bigkey 的方法不少，这里介绍两种比较常用的方法，也是 Daas 平台分析 Bigkey 使用的两种方式，分别是 Bigkeys 命令分析法、RDB 文件分析法。
3.1 scan 命令分析
Redis4.0 及以上版本提供了 --Bigkeys 命令，可以分析出实例中每种数据结构的 top 1 的 Bigkey，同时给出了每种数据类型的键值个数以及平均大小。执行 --Bigkeys 命令时候需要注意以下几点：
建议在 slave 节点执行，因为 --Bigkeys 也是通过 scan 完成的，可能会对节点造成阻塞。
建议在节点本机执行，这样可以减少网络开销。
如果没有从节点，可以使用 --i 参数，例如 (--i 0.1 代表 100 毫秒执行一次)。
--Bigkeys 只能计算每种数据结构的 top1，如果有些数据结构有比较多的 Bigkey，是查找不出来的。
Daas 平台集成了基于原生 --Bigkeys 代码实现的查询 Bigkey 的方式，这个方式的缺点是只能计算每种数据结构的 top1，如果有些数据结构有比较多的 Bigkey，是查找不出来的。该方式相对比较安全，已经开放出来给业务开发同学使用。
3.2 RDB 文件分析
借助开源的工具，比如 rdb-tools，分析 Redis 实例的 RDB 文件，找出其中的 Bigkey，这种方式需要生成 RDB 文件，需要注意以下几点：
建议在 slave 节点执行，因为生成 RDB 文件会影响节点性能。
需要生成 RDB 文件，会影响节点性能，虽然在 slave 节点执行，但是也是有可能造成主从中断，进而影响到 master 节点。
Daas 平台集成了基于 RDB 文件分析代码实现的查询 Bigkey 的方式，可以根据实际需求自定义填写 N，分析的 top N 个 Bigkey。该方式相对有一定风险，只有 DBA 有权限执行分析。
3.3 Bigkey 巡检
通过巡检，可以暴露出隐患，提前解决，避免故障的发生，进行全网 Bigkey 的巡检，是避免 Bigkey 故障的比较好的方法。由于全网 Redis 实例数量非常大，分析的速度比较慢，使用当前的分析方法很难完成。为了解决这个问题，存储研发组分布式数据库同学计划开发一个高效的 RDB 解析工具，然后通过大规模解析 RDB 文件来分析 Bigkey，可以提高分析速度，实现 Bigkey 的巡检。
四、 Bigkey 处理优化
4.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
4.2 Bigkey 分析工具优化
我们全网 Redis 集群有 2200 以上，实例数量达到 4.5 万以上，有的比较大的集群的实例数量达到了 1000 以上，前面提到的两种 Bigkey 分析工具还都是实例维度分析，对于实例数量比较大的集群，进行全集群分析也是比较耗时的，为了提高分析效率，从以下几个方面进行优化：
可以从集群维度选择全部 slave 进行分析。
同一个集群的相同服务器 slave 实例串行分析，不同服务器的 slave 实例并行分析，最大并发度默认 10，同时可以分析 10 个实例，并且可以自定义输入执行分析的并发度。
分析出符合 Bigkey 规定标准的所有 key 信息：大于 1MB 的 string 类型的所有 key，如果不存在就列出最大的 50 个 key；hash、list、set、zset 等类型元素个数大于 2000 的所有 key，如不存在就给出每种类型最大的 50 个 key。
增加暂停、重新开始、结束功能，暂停分析后可以重新开始。
4.3 水平扩容迁移优化
目前情况，我们有一些 Bigkey 的发现是被动的，一些是在水平扩容时候发现的，由于 Bigkey 的存在导致扩容失败了，严重的还触发了 master-slave 的故障切换，这个时候可能已经造成业务程序访问超时，导致了可用性下降。
我们分析了 Daas 平台的水平扩容时迁移 key 的过程及影响参数，内容如下：
（1）【cluster-node-timeout】：控制集群的节点切换参数，master 堵塞超过 cluster-node-timeout/2 这个时间，就会主观判定该节点下线 pfail 状态，如果迁移 Bigkey 阻塞时间超过 cluster-node-timeout/2，就可能会导致 master-slave 发生切换。
（2）【migrate timeout】：控制迁移 io 的超时时间，超过这个时间迁移没有完成，迁移就会中断。
（3）【迁移重试周期】：迁移的重试周期是由水平扩容的节点数决定的，比如一个集群扩容 10 个节点，迁移失败后的重试周期就是 10 次。
（4）【一个迁移重试周期内的重试次数】：在一个起迁移重试周期内，会有 3 次重试迁移，每一次的 migrate timeout 的时间分别是 10 秒、20 秒、30 秒，每次重试之间无间隔。
比如一个集群扩容 10 个节点，迁移时候遇到一个 Bigkey，第一次迁移的 migrate timeout 是 10 秒，10 秒后没有完成迁移，就会设置 migrate timeout 为 20 秒重试，如果再次失败，会设置 migrate timeout 为 30 秒重试，如果还是失败，程序会迁移其他新 9 个的节点，但是每次在迁移其他新的节点之前还会分别设置 migrate timeout 为 10 秒、20 秒、30 秒重试迁移那个迁移失败的 Bigkey。这个重试过程，每个重试周期阻塞（10+20+30）秒，会重试 10 个周期，共阻塞 600 秒。其实后面的 9 个重试周期都是无用的，每次重试之间没有间隔，会连续阻塞了 Redis 实例。
（5）【迁移失败日志】：迁移失败后，记录的日志没有包括迁移节点、solt、key 信息，不能根据日志立即定位到问题 key。
我们对这个迁移过程做了优化，具体如下：
（1）【cluster-node-timeout】：默认是 60 秒，在迁移之前设置为 15 分钟，防止由于迁移 Bigkey 阻塞导致 master-slave 故障切换。
（2）【migrate timeout】：为了最大限度减少实例阻塞时间，每次重试的超时时间都是 10 秒，3 次重试之间间隔 30 秒，这样最多只会连续阻塞 Redis 实例 10 秒。
（3）【重试次数】：迁移失败后，只重试 3 次（重试是为了避免网络抖动等原因造成的迁移失败），每次重试间隔 30 秒，重试 3 次后都失败了，会暂停迁移，日志记录下 Bigkey，去掉了其他节点迁移的重试。
（4）【优化日志记录】：迁移失败日志记录迁移节点、solt、key 信息，可以立即定位到问题节点及 key。
五、总结
本文通过对 Bigkey 的分析，重点介绍了在运维中对 bigkey 问题的处理思路、解决方式。首先是需要从源头治理，防止 Bigkey 形成，DBA 应该加强对业务开发同学 bigkey 相关问题的宣导；其次是需要具备及时发现的能力，这个也是我们现在的不足之处。我们后面会从 Bigkey 巡检、Bigkey 分析工具的这两个方面，提高 Bigkey 发现能力。