Skip to content

Redis中的大Key与热Key问题

1. 大 Key 问题 (Big Key Problem)

1.1 什么是大 Key？

大 Key 问题并非指 Key 本身过大，而是指与 Key 关联的 Value 所占用的内存空间过大。 对于多大的 Key 才算“大”，并没有一个统一的硬性标准，通常根据业务场景和性能要求来评估。一般来说，可以参考以下经验值：

  • String 类型：Value 的大小超过 1MB。
  • 集合类型（List, Hash, Set, ZSet）：成员数量超过 10,000 个。

在一些高并发、低延迟的场景中，即使只有 10KB 也可能被视为大 Key。

1.2 大 Key 带来的危害

大 Key 会对 Redis 的性能和稳定性产生多方面的负面影响：

  • 内存占用过高：大 Key 会消耗大量内存，可能导致内存不足，触发内存淘汰策略，甚至在极端情况下导致 Redis 实例崩溃。
  • 性能下降：对大 Key 的读写操作会消耗更多的 CPU 和内存资源，增加内存碎片，从而降低 Redis 的整体性能。
  • 阻塞其他操作：Redis 的核心操作是单线程的，对大 Key 的某些操作（如删除）可能会长时间阻塞主线程，导致其他客户端请求无法得到及时响应。
  • 网络拥塞：读取一个大 Key 会产生大量的网络流量，可能占满服务器或局域网的带宽，影响其他服务的正常运行。
  • 集群负载不均：在 Redis 集群模式下，数据分片的基本单位是 Key。一个大 Key 会导致数据和访问压力集中在某个节点上，造成负载倾斜。

1.3 如何分析和排查大 Key？

发现潜在的大 Key 是解决问题的第一步，可以通过以下几种方式进行排查：

  • redis-cli --bigkeys：Redis 自带的 bigkeys 命令可以扫描整个数据库，并统计每种数据类型中最大的 Key。这个命令对于分析 String 类型的大 Key 很有用，但对于集合类型，它只统计成员数量，而不是实际内存占用。
  • MEMORY USAGE 命令：对于 Redis 4.0 及以上版本，可以使用 MEMORY USAGE <key> 命令来获取指定 Key 所占用的内存字节数。 通过遍历所有 Key 并执行此命令，可以找出内存占用较大的 Key。
  • SCAN 命令结合 STRLEN 或集合类型的 *LEN 命令：通过 SCAN 命令迭代数据库中的所有 Key，然后根据不同类型使用如 STRLEN、LLEN、HLEN、SCARD、ZCARD 等命令来判断其大小或成员数量。
  • 第三方工具：可以利用如 redis-rdb-tools 等开源工具来分析 RDB 快照文件，从而找出内存占用大的 Key。

1.4 大 Key 问题的解决方案

针对已经发现的大 Key，可以采取以下策略进行优化和解决：

  • 拆分大 Key：这是最直接有效的方法。将一个大的集合类型 Key 拆分成多个小的 Key。例如，一个包含 100 万用户的哈希表可以按用户 ID 的范围或哈希值拆分成 100 个小的哈希表，每个包含 1 万用户。读取时可以使用 MGET 或 MHMGET 等批量操作来获取数据。
  • 数据压缩：对于 String 类型的 Value，在存入 Redis 前可以使用 Gzip、Snappy 等压缩算法进行压缩，读取时再解压。这可以显著减小内存占用，但会增加 CPU 的计算开销。
  • 选择合适的数据结构：根据业务场景选择更优的数据结构。例如，如果只需要判断一个元素是否存在于一个大集合中，可以考虑使用内存效率更高的布谷鸟过滤器（Cuckoo Filter）或布隆过滤器（Bloom Filter）。
  • 设置合理的过期时间：为 Key 设置恰当的 TTL（Time-To-Live），确保不再使用的数据能够被自动清理，避免数据无限制累积成大 Key。
  • 异步删除：对于已经存在的大 Key，不要直接使用 DEL 命令删除，因为它会阻塞主线程。应优先使用 Redis 4.0 引入的 UNLINK 命令，该命令会在后台异步删除 Key，避免阻塞。

2. 热 Key 问题 (Hot Key Problem)

2.1 什么是热 Key？

热 Key，也称为热点 Key，指的是在短时间内被极高频率访问的 Key。 当大量请求集中访问某个特定的 Key 时，就会产生热 Key 问题。

2.2 热 Key 带来的危害

热 Key 问题同样会对系统造成严重影响：

  • 流量集中和单点瓶颈：由于请求都集中在少数几个 Key 上，这些 Key 所在的 Redis 节点会承受巨大的访问压力，其 CPU、内存和网络带宽等资源可能被耗尽，达到物理网卡上限，而集群中的其他节点却相对空闲。
  • 影响其他请求：由于 Redis 是单线程处理请求的，当一个热 Key 的请求处理不过来时，会影响到同一个实例上其他 Key 的正常访问。
  • 缓存击穿和雪崩风险：如果热 Key 失效或被删除，大量的请求会瞬间穿透缓存，直接访问后端的数据库，可能导致数据库压力剧增甚至宕机，引发缓存雪崩。

2.3 如何分析和排查热 Key？

及时发现热 Key 对于预防系统故障至关重要：

  • 凭借业务经验预估：根据业务特性，可以提前预估哪些 Key 可能会成为热 Key，例如秒杀活动中的商品 ID、热门新闻或视频的 ID 等。
  • 客户端收集：在客户端代码中加入统计逻辑，收集并上报 Key 的访问频率。
  • 代理层分析：如果使用了如 Twemproxy 或自研的 Redis 代理，可以在代理层进行请求统计。
  • Redis 自带命令：
    • MONITOR 命令：可以实时捕获 Redis 服务器接收到的所有命令。通过分析输出，可以统计出高频访问的 Key。但在高并发场景下，MONITOR 命令会带来性能损耗和内存激增的风险。
    • HOTKEYS 参数 (Redis 4.0.3+)：执行 redis-cli --hotkeys 可以发现热点 Key，但如果 Key 数量庞大，执行过程可能会比较慢。
  • 抓包分析：通过在 Redis 服务器端抓取网络包并根据 RESP 协议进行分析，也可以统计出热 Key。这种方法虽然精确，但开发和维护成本较高。

2.4 热 Key 问题的解决方案

解决热 Key 问题的核心思想是将集中的访问压力分散开：

  • 使用二级缓存/本地缓存：在应用服务器端（客户端）使用内存缓存（如 Guava Cache, Caffeine, Ehcache 或简单的 HashMap）来缓存热 Key 的数据。大部分请求会直接命中本地缓存，从而大大减轻对 Redis 的压力。
  • 读写分离：如果 Redis 部署了主从模式，可以将读请求分散到多个从节点上，分担主节点的读取压力。
  • 数据分片/Key 的复制：将一个热 Key 复制成多个新的 Key（例如，hotkey:1, hotkey:2, ..., hotkey:N），并将它们分散存储在不同的 Redis 实例上。当访问这个热 Key 时，客户端随机选择一个副本进行读取，从而将请求压力分散到多个节点。
  • 使用代理和负载均衡：通过在应用和 Redis 之间增加一个代理层，可以在代理层实现更复杂的负载均衡策略，或者对于热 Key 的请求进行特殊处理，比如直接从代理的本地缓存返回。
  • 限流和熔断：在应用层针对特定热 Key 的请求进行限流，当请求超过阈值时，直接拒绝或返回一个兜底数据，避免所有请求都打到 Redis 上。