- 如何定义大 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 的处理能力得到了大幅提升。通过这样的设计,我们可以做到实时的热点监控,并及时通过流控去止损;通过热点迁移,我们能做到自动的热点隔离和快速的容量扩充。