[转帖]浅谈Redis大Key与热Key

https://www.cnblogs.com/jelly12345/p/16424080.html

• 如何定义大 Key 和 热 Key
  • 如何定义大 Key
  • 如何定义热 Key
• 大 Key 和 热 Key 产生的原因
• 大 Key 和 热 Key 有哪些危害
  • 大 Key 的危害
  • 热 Key 的危害
• 如何发现大 Key 和 热 Key
  • 通过原生自带的方式
    • 通过 redis-cli 的 bigkeys 和 hotkeys 参数查找大 Key 和热 Key
    • 通过 redis-cli 的内置命令查找大 Key 和热 Key
    • 通过 redis-cli 的 MONITOR 查找热 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 的处理能力得到了大幅提升。通过这样的设计，我们可以做到实时的热点监控，并及时通过流控去止损；通过热点迁移，我们能做到自动的热点隔离和快速的容量扩充。

参考资料

1. 阿里云数据库Redis
2. 美团万亿级 KV 存储架构与实践
3. 有赞透明多级缓存解决方案TMC

所有博文均为原著，如若转载，请注明出处！