- 如何定义大 Key 和 热 Key
- 大 Key 和 热 Key 产生的原因
- 大 Key 和 热 Key 有哪些危害
- 如何发现大 Key 和 热 Key
- 如何解决大 Key 热 Key
- 业界采用的一些定制化解决方案
- 参考资料
如何定义大 Key 和 热 Key
下述例子中的具体数值仅供参考，在实际的业务中，需要根据 Redis 的实际业务场景进行综合判定。
如何定义大 Key
通常以 Key 的大小和Key中成员的数量来综合判定，例如：
- Key 本身的数据量过大：一个 String 类型的 Key，它的值为 5MB。
- Key 中的成员过多：一个 ZSET 类型的 Key，它的成员数量为 10,000个。
- Key 中成员的数据量过大：一个 Hash 类型的 Key，它的成员数量虽然只有 1,000个，但这些成员的 Value(值)总大小为 100MB。
如何定义热 Key
通常以其接收到的 Key 被请求频率来判定，例如：
- QPS 集中在特定的 Key：Redis 实例的总QPS为 10,000, 而其中一个 Key 的每秒访问量达到了 7000。
- 带宽利用率集中在特定的 Key：对于一个拥有上千个成员且总大小为 1MB 的 HASH Key，每秒发送大量的 HGETALL 请求。
- CPU使用时间占比集中在特定的 Key：对于一个拥有数万个成员的 Key(ZSET类型)，每秒发送大量的 ZRANGE 请求。
大 Key 和 热 Key 产生的原因
未正确使用 Redis、业务规划不足、无效数据的堆积、访问量突增等都会产生大 Key 与 热 Key。
-
大 Key
- 在不适用的场景下使用 Redis，易造成 Key 的 Value 过大，如使用 String 类型的 Key 存放大体积的二进制文件型数据。
- 业务上线前规划设计不足，没有对 Key 中成员进行合理的拆分，造成个别 Key中的成员数过多。
- 未定期清理无效数据，造成如 HASH 类型 Key 中的成员持续地增加。
- 使用 LIST 类型 Key 的业务消费側发生代码故障，造成对应 Key 的成员只增不减。
-
热 Key
- 预期外的访问量陡增，如突然出现的爆款商品、访问量暴涨的新闻热点、直播间某主播搞活动带来的大量刷屏点赞等。
大 Key 和 热 Key 有哪些危害
大 Key 的危害
- 内存不均：单 Value 较大时候，可能会导致节点之间内存使用不均匀，导致负载不均衡。
- 阻塞请求：redis 为单线程，单 Value 较大读写需要较长的处理时间，会阻塞后续的请求处理。
- 阻塞网络：单 Value 较大时会占用服务器网卡较多带宽，可能导致出口带宽打满，影响该服务器傻姑娘单其它 Redis 实例或应用。
热 Key 的危害
- CPU飙升：可能会导致 CPU 使用率飙升到 100%，影响服务器的稳定性和可用性。
- 阻塞网络：流量集中，达到物理网卡上限，影响其它 Key 的访问(大 Key 也可能导致该问题)
- 缓存击穿：请求过多，缓存分片被打垮，不能通过扩容解决，且不能发挥集群多分片的优势。
如何发现大 Key 和 热 Key
发现大 key 和热 key 的手段主要有一下几种，1.使用 redis 原生自带的方式；2. 使用开源工具；3. 业务层进行统计分析；4. 代理层进行统计分析。下面我们来逐个进行分析。
通过原生自带的方式
通过 redis-cli 的 bigkeys 和 hotkeys 参数查找大 Key 和热 Key
redis 原生提供了一些参数来统计 big key 和 hot key，比如:
redis-cli -- bigkeys命令来统计大 key。
- 优点
- 方便、快速、安全
- 缺点
- 分析结果不可定制化，准确性和时效性差。比如 bigkeys 只能返回 Key 的整体统计信息与每个数据类型中 Top1 的大 Key，big Key 仅能分析六种数据类型(STRING、LIST、HASH、ZSET、STREALM)。如果我们只想分析 STRING 类型的大 Key 或者找出成员数量超过 10 个的 HASH Key，则 bigkeys 命令无法直接实现该类需求。
通过 redis-cli 的内置命令查找大 Key 和热 Key
根据大 key 和热 key 的定义，我们也可以直接使用 redis 提供的一些命令进行分析，比如对于 STRING 类型：执行
STRLEN命令，返回对应 Key 的 Value 的字节数；对于 LIST 类型：执行LLEN命令，返回对应 Key 的列表长度等。
- 优点
- 方便、对线上服务影响小。
- 缺点
- 返回的 Key 序列化长度并不等同于它在内存空间中的真实长度(因为redis存储的是一个个对象，而不仅仅是value)，因此不够准确，仅可作为参考。
通过 redis-cli 的 MONITOR 查找热 Key
Redis 的 MONITOR 命令能够忠实打印出 Redis 中的所有请求(类似 MySQL 的 general log)，包括时间信息、Client 信息、命令以及 Key 信息。在发生紧急情况时，可以通过短暂执行 MONITOR 命令并将返回信息输入至文件，在关闭 MONITOR 命令后，对文件中请求进行归类分析，找出这段时间中的热 Key。由于 MONITOR 命令对 Redis 的性能消耗较大，非特殊情况不推荐使用 MONITOR 命令。
- 优点
- 方便、安全
- 缺点
- 会占用 CPU、内存、网络资源、实效性和准确性较差。
通过开源工具
除了使用 redis 原生自带的参数或命令外，我们还可以使用一些开源工具对 rdb 文件进行解析统计。比如可以使用Redis-rdb-tools，它是通过 Python 进行编写，支持定制化分析 Redis RDB 快照的开源工具。可以根据自己的精细化需求，全面地分析 Redis 实例中所有 Key 的内存占用情况，同时也支持灵活地分析查询。
- 优点
- 支持定制化分析，对线上服务无影响。
- 缺点
- 实效性差，RDB 文件较大时耗时较长。
客户端统计分析
除了在 redis 側进行分析统计，也可以在业务側对热 Key 进行统计，比如在 Redis 的 SDK 中封装相应的逻辑，在业务层增加对 Redis 的访问进行记录并异步汇总分析。
- 优点
- 可准切并及时地定位热 Key
- 缺点
- 业务代码复杂度的增加，同时可能会降低一些客户端性能。
代理层统计分析
除了在 Redis 服务侧，业务側进行统计分析，部分云厂商在售卖它们的 Redis 产品时，一般都会提供代理(Proxy), 用于集群模式下的读写分离等功能，当然不止这一个功能，比如Ali 的云数据库 Redis 产品，它的 Proxy 还能对热 Key 进行分析统计，并且进行缓存，这样可以降低 Redis 服务端的访问压力。其它云厂商也纷纷都有自己的代理。
- 优点
- 对业务代码无侵入
- 对线上服务无影响，甚至可以降低服务端的压力
- 缺点
- 一般只有云厂商才提供，不具有普遍性。
- 代理层缓存的 Key 的查询结果在有效时间内不会更新，需要业务侧允许一段时间的缓存不一致。
- 统计不是十分准确，每一个 Proxy 只能统计自己的热 Key。
如何解决大 Key 热 Key
处理大 Key
- 对大 Key 进行拆分
- 对大 Key 进行清理
- 监控 Redis 的内存水位
- 对过期数据进行定期清理
处理热 Key
- 在集群模式中对热 Key 进行复制
- 使用读写分离架构
- 代理层的查询缓存(比如Ali的 QueryCache)
业界采用的一些定制化解决方案
有赞采用的方案
有赞有自己的TMC, 它是一个缓存解决方案，用于帮助应用层解决缓存使用过程中出现的热点访问问题。主要是通过增加本地缓存来降低对下游缓存服务的冲击。
美团采用的方案
美团有自己的 KV 存储服务Squirrel。它在节点内会对每个请求 Key 进行统计，当满足热点 Key 时，对该热点 Key 进行流控，同时检控服务会周期性的去所有 Redis 上查询统计到的热点 Key，如果有热点 Key，监控服务就会把热点 Key 所在 Slot 上报到迁移服务。迁移服务这时会把热点主从节点加到这个集群中，然后把热 Slot 迁移到这个热点主从上，因为热点主从上只有热点 Slot 的请求，所以热点 Key 的处理能力得到了大幅提升。通过这样的设计，我们可以做到实时的热点监控，并及时通过流控去止损；通过热点迁移，我们能做到自动的热点隔离和快速的容量扩充。