目录

一、BigKey 的概念

1.1 普通 key 的设计规则

1.2 BigKey 的定义

1.3 BigKey 存在的问题

二、BigKey 的发现与解决方案

第一种方式：redis-cli --bigkeys

第二种方式：scan扫描

第三种方式：第三方工具

第四种方式：网络监控

---

一、BigKey 的概念

1.1 普通 key 的设计规则

遵循的基本格式：[业务名称]:[数据名]:[id]（login:user:1）

key 的长度建议：长度不超过 44 字节（否则会占用更多内存）

key 的设计建议：建议尽量不要包含特殊字符

1.2 BigKey 的定义

BigKey 通常以 Key 的大小和 Key 中成员的数量来综合判定，例如：

• Key 本身的占用内存过大：一个 String 类型的 Key，它的值为 5 MB。

• Key 中的成员个数过多：一个 ZSET 类型的 Key，它的成员数量为10,000个。

• Key 占用内存大的同时数量众多：一个Hash类型的Key，它的成员数量虽然只有1,000个但这些成员的Value（值）总大小为100 MB。

推荐大小与数量：

• 单个key的value小于10KB

• 对于集合类型的key，建议元素数量小于1000

1.3 BigKey 存在的问题

1. 网络阻塞导致带宽被占满：对 BigKey 执行读请求时，少量的 QPS（每秒查询率）就可能导致带宽使用率被占满，导致 Redis 实例，乃至所在物理机变慢。

2. 内存资源分配不均匀：BigKey 所在的 Redis 实例内存使用率远超其他实例，无法使数据分片的内存资源达到均衡

3. 计算耗时久导致线程阻塞：对元素较多的 hash、list、zset 等做运算会耗时较久，使主线程被阻塞。

4. 序列化导致 CPU 压力飙升：对 BigKey 的数据序列化和反序列化会导致 CPU 的使用率飙升，影响 Redis 实例和本机其它应用

二、BigKey 的发现与解决方案

第一种方式：redis-cli --bigkeys

redis-cli --bigkeys：利用 redis-cli 提供的 --bigkeys 参数，可以遍历分析所有 key，并返回Key 的整体统计信息与每个数据的 Top1 的 big key

第二种方式：scan扫描

scan扫描：自己编程，利用 scan 扫描 Redis 中的所有 key，利用strlen、hlen 等命令判断 key 的长度（此处不建议使用MEMORY USAGE）

第三种方式：第三方工具

第四种方式：网络监控

网络监控:自定义工具，监控进出 Redis 的网络数据，超出预警值时主动告警(阿里云 Redis 监控)