一个无 TTL 的 Redis Hash 长到 58GB，把线上缓存命中率打到 41%：一次缓存雪崩的完整复盘

一、现象：凌晨 3 点的告警，比想象中严重

2025-07-12 03:17，监控群弹出第一条告警：Redis 主节点 used_memory 达到 58.7GB，逼近 maxmemory 64GB 上限。20 分钟后，业务侧开始报"接口变慢"。

关键数字先列出来，后面复盘都用得上：

• 实例规格：64GB 主从，maxmemory-policy allkeys-lru（默认值，没人改过）；
• used_memory 从 7 月初的 51.2GB 涨到 58.7GB，周增速约 1.4GB，此前 18 个月增速从 30MB/周 一路涨到 1.4GB/周，但没人看这条曲线；
• 03:38 开始 keyspace_hits 占比（命中率）从长期稳定的 98.2% 掉到 41%，持续 40 分钟；
• 同一窗口 MySQL 主库 QPS 从 1.2k 冲到 9.4k，慢查询（>200ms）从 0 条涨到 214 条；
• 03:58 应急处置完成，命中率回落到 97% 以上，全程业务侧感知 约 25 分钟的 P2 级劣化。

影响面：下单链路 RT P99 从 180ms 涨到 1.9s，客服工单 +37 条。没到 P1，但离熔断只差一个突发流量。

二、根因：不是"内存不够"，是一个没设 TTL 的 Hash 吃掉了 53GB

MEMORY USAGE 定位后发现元凶：

127.0.0.1:6379> MEMORY USAGE user_behavior_digest
(integer) 56637087104   # ≈ 52.8GB
127.0.0.1:6379> TYPE user_behavior_digest
hash
127.0.0.1:6379> HLEN user_behavior_digest
(integer) 89314267      # 近 9000 万 field

这是一个"用户行为聚合"Hash：field = userId，value = JSON 行为摘要。2024 年 1 月上线时设计意图是"滚动 7 天"，但代码里只有 HSET，没有任何 HDEL / 过期逻辑，也没有 TTL。18 个月只进不出，从 800MB 长到 52.8GB，占实例 58.7GB 的 90%。

机制上有三层叠加，缺一层都不会炸：

1. 无界写入：单 Key Hash 没有"大小上限"约束，业务代码 HSET 是幂等的，写入方完全无感知；
2. LRU 淘汰策略反噬：allkeys-lru 意味着这个热 Hash 里最冷的 field 会先被淘汰——淘汰的是"正确数据"，于是业务读 miss 后回源 My

三、Redis 内存淘汰策略的失效：LRU 为何成了“帮凶”

在 Redis 的默认配置中，allkeys-lru 是一种基于“最近最少使用”算法的内存淘汰策略，其核心逻辑是：当内存达到 maxmemory 限制时，系统会优先淘汰最近最少使用的键，以腾出空间。然而在本次事件中，这一策略反而成了“罪魁祸首”，其底层逻辑的缺陷在特定场景下暴露无遗。

LRU 机制的“冷热数据混淆”问题

allkeys-lru 的设计初衷是通过追踪每个键的访问时间，优先淘汰冷数据，从而释放内存。但在本次事件中，问题的根源在于该策略对“冷热数据”判断的失真。具体来说，user_behavior_digest 这个 Hash 的结构导致了 LRU 算法的异常行为：由于该 Hash 的 field 数量高达 9000 万，且每个 field 的访问频率存在显著差异，LRU 无法准确区分“真正冷的数据”和“看似冷实则热的数据”。

例如，某些用户行为字段（如登录记录）可能每天被频繁访问，但因 Redis 的 LRU 算法仅记录键的最后一次访问时间，而无法感知字段的实时使用频率。当某个字段因业务需求短暂未被访问时，即使它仍属于热数据，也可能被标记为“冷数据”并被优先淘汰。这种“误判”直接导致缓存命中率骤降，进而引发数据库压力激增。

LRU 与 Hash 结构的“负向协同”

更致命的是，user_behavior_digest 的 Hash 结构与 LRU 策略形成了“负向协同”。Hash 类型的内部实现是使用字典（dict）结构，每个 field 作为键存储在字典中，而 LRU 算法需要为每个键维护访问时间戳。当 Hash 的 field 数量巨大时，每个 field 的访问时间戳更新会带来额外的内存开销和计算开销。在本案例中，由于 Hash 中的 field 数量高达 9000 万，Redis 的 LRU 算法需要频繁维护大量时间戳，导致内存占用和 CPU 消耗急剧上升。

更关键的是，当 user_behavior_digest 的内存占用达到 52.8GB 时，Redis 的 LRU 策略开始频繁触发淘汰。然而，由于该 Hash 的 field 数量庞大，淘汰的“冷数据”实际上可能包含业务中仍需频繁访问的热字段。例如，某些用户行为字段可能因业务逻辑的特殊性（如高并发场景下的突发访问）而需要长期保留，但 LRU 算法却将其误判为“冷数据”并淘汰。这种误判导致缓存命中率从 98.2% 猛跌至 41%，形成“缓存雪崩”的连锁反应。

LRU 策略的局限性与改进方向

allkeys-lru 的局限性在本案例中暴露无遗，其核心问题在于无法动态适应数据访问模式的变化。对于类似 user_behavior_digest 这样的“长尾数据”场景，LRU 策略的静态规则难以满足需求。更进一步，Redis 的 LRU 实现还存在一个“局部性原理”失效的问题：当某个键的访问频率突然升高时，其时间戳会被更新，但该键的后续访问仍可能因时间戳未及时更新而被误判为冷数据。

为避免此类问题，可考虑以下改进方向：

1. 混合淘汰策略：将 allkeys-lru 与 volatile-ttl 或 volatile-lfu 策略结合，通过引入“时间衰减因子”或“访问频率权重”优化淘汰逻辑。
2. 分片与分层设计：将高并发的业务数据拆分为多个独立的 Hash 或使用 Redis 的模块化功能（如 RedisJSON），避免单个 Key 占用过大的内存空间。
3. 动态监控与阈值调整：对关键业务 Key 的内存占用和访问频率进行实时监控，设置动态阈值，当检测到异常增长时自动触发预警或调整淘汰策略。

案例启示：警惕“隐性内存消耗”

本次事件的核心教训在于：Redis 的内存淘汰策略并非万能，其效果高度依赖于数据访问模式和存储结构。对于类似 user_behavior_digest 这样的“长尾数据”场景，仅依赖默认策略可能无法有效避免内存危机。业务方需要深入理解数据访问规律，结合监控系统和淘汰策略的动态调整，才能构建更健壮的缓存架构。

四、Redis 内存碎片的隐形杀手：碎片化如何蚕食有效内存

在 Redis 的内存管理中，"碎片化"始终是被低估的隐形杀手。当 Redis 实例长期运行、频繁进行内存分配与释放时，内存碎片会像幽灵般悄然积累，最终导致"内存看似充足，实则无法使用"的诡异现象。本次事件中，58.7GB 的 used_memory 与实际可用内存之间的偏差，正是碎片化对内存利用率的侵蚀结果。

内存碎片的形成机制与分类

Redis 使用 jemalloc 内存分配器，其内存管理以 slab 分配机制为核心。当 Redis 需要分配内存时，jemalloc 会从预分配的 slab 中获取块，这些块的大小由内存分配请求的大小决定。但当某些内存块被释放后，若无法被后续的分配请求复用，就会形成内存碎片。

内存碎片可分为外部碎片和内部碎片两种类型：

1. 外部碎片：指内存中存在大量无法满足新分配请求的小块空闲内存，但这些空闲内存的总和大于单次请求所需内存。例如，当 Redis 释放一个 1MB 的内存块后，若后续需要 500KB 的内存，而系统中恰好没有足够的连续空闲内存，就会出现外部碎片。

2. 内部碎片：指分配给对象的内存块大小大于实际所需，造成空间浪费。例如，当 Redis 为一个 100 字节的字符串分配 128 字节的内存块时，剩余的 28 字节即为内部碎片。

在 Redis 的使用场景中，外部碎片更为常见。当大量小对象被频繁创建和销毁时，内存分配器会不断分割和合并内存块，导致碎片化程度加深。而在本次事件中，user_behavior_digest 这个 Hash 的结构进一步加剧了碎片化问题。

Hash 结构与碎片化的负向协同

Hash 类型的内存占用特性使其成为内存碎片的高发区。Redis 的 Hash 结构使用 dict（字典）实现，每个 field 作为键存储在字典中，而每个键值对需要额外的内存开销用于维护哈希表的链表结构、哈希表的负载因子调整等。当 Hash 的 field 数量达到数千万级别时，这些额外的开销会显著增加内存占用。

更关键的是，Hash 的字段数量和值的大小差异会直接导致内存碎片的累积。例如，user_behavior_digest 中的每个 field 存储的是 JSON 编码的用户行为摘要，这些值的大小可能差异极大。当 Redis 为某些字段分配较大的内存块后，后续分配的字段可能需要更小的内存块，导致无法复用已有的空闲内存，从而产生外部碎片。

此外，Redis 的内存分配器在处理 Hash 类型时，会为每个 field 分配独立的内存块。即使某些 field 被频繁访问，其内存块也不会被回收，而是继续保留在内存中。这种"永不释放"的特性，使得 Hash 结构在长期运行后容易成为内存碎片的温床。

碎片化对内存淘汰策略的影响

当 Redis 实例出现内存碎片时，used_memory 会显示为一个虚高的值。例如，在本次事件中，used_memory 为 58.7GB，但实际可用内存可能远低于这个数值。这种虚高值会误导运维人员，使其误以为内存资源充足，从而忽视内存淘汰策略的触发条件。

更危险的是，内存碎片会直接影响 Redis 的内存淘汰策略。当 Redis 需要释放内存时，它会优先淘汰那些"冷数据"键，但若内存碎片导致无法释放足够的连续内存，即使执行了淘汰操作，也无法满足内存需求。这会导致 Redis 持续触发淘汰策略，形成"淘汰-碎片-再淘汰"的恶性循环。

在本次事件中，user_behavior_digest 的内存碎片可能使得 Redis 在执行 LRU 淘汰时，无法及时释放足够的内存，导致内存占用持续增长。同时，由于 Hash 结构本身的碎片化特性，淘汰的"冷数据"往往包含业务中仍需访问的热字段，进一步加剧了缓存雪崩的风险。

碎片化的检测与缓解策略

Redis 提供了 MEMORY USAGE 命令用于检测内存使用情况，但其对碎片化的分析能力有限。要深入分析碎片化问题，需要结合 INFO memory 命令中的 memfrag 数据。memfrag 表示 Redis 内存分配器中未被使用的内存碎片总量，其值越高，说明内存碎片越严重。

此外，Redis 的内存分配器提供了 --jemalloc 参数用于配置 jemalloc 的行为，例如调整 slab 的大小、限制内存碎片的累积等。在实际运维中，可以通过调整 jemalloc 的参数来优化内存碎片的管理，例如：

• 调整 slab 分配粒度：通过设置 --jemalloc 的 slab-size 参数，可以控制内存分配器分配内存块的大小，从而减少碎片化。
• 启用内存碎片回收：某些 jemalloc 的版本支持内存碎片回收机制，可以定期清理无法复用的内存碎片。
• 限制单个 Key 的内存占用：通过设置 maxmemory-policy 或使用 Redis 的模块化功能（如 RedisJSON），避免单个 Key 占用过大的内存。

在本次事件中，user_behavior_digest 的内存碎片可能是导致 Redis 内存占用异常的重要原因之一。通过深入分析内存碎片的形成机制及其对内存淘汰策略的影响，可以更全面地理解 Redis 内存管理的复杂性，并采取针对性的优化措施。

Redis 内存预分配与碎片化缓解：如何避免内存分配的隐形陷阱

在 Redis 的内存管理中，"内存预分配"（Memory Pre-allocation）是一个常被忽视但影响深远的技术点。它不仅关系到 Redis 实例的内存利用率，更与内存碎片化的形成和缓解密切相关。本次事件中，user_behavior_digest 这个 Hash 的内存占用异常，本质上与 Redis 的内存分配策略及其预分配机制的配置密切相关。通过深入剖析这一机制，我们可以理解为何某些场景下 Redis 会出现"内存看似充足，实则无法使用"的诡异现象，并探索如何通过优化预分配策略来缓解碎片化问题。

内存预分配的核心逻辑

Redis 采用 jemalloc 作为内存分配器，其核心设计目标是通过高效的内存管理减少碎片化和内存浪费。在默认配置下，jemalloc 采用"按需分配"（On-demand Allocation）的策略，即当 Redis 需要内存时，jemalloc 会动态分配所需大小的内存块。然而，这种策略在长期运行的场景中可能导致内存碎片的累积，尤其是在频繁分配和释放小内存块的场景下。

为解决这一问题，Redis 支持通过配置参数实现内存预分配（Memory Pre-allocation）。具体来说，Redis 会根据当前内存使用情况和预分配策略，提前为某些关键操作（如持久化、命令执行）预留内存空间。这一机制的初衷是减少因频繁分配和释放内存导致的碎片化，同时提升 Redis 的性能表现。

在 Redis 的配置文件中，内存预分配主要通过以下参数控制：

• maxmemory：设置 Redis 实例的内存上限，超过此值时触发内存淘汰策略。
• maxmemory-policy：定义内存淘汰策略（如 allkeys-lru、volatile-lfu 等）。
• jemalloc 配置：通过 --jemalloc 参数调整 jemalloc 的行为，例如 slab-size（控制 slab 分配粒度）、narenas（控制内存区域的数量）等。

预分配与碎片化的负向协同

尽管内存预分配旨在减少碎片化，但在某些场景下，它可能反而加剧碎片化问题。例如，当 Redis 实例的内存需求存在周期性波动时，预分配策略可能导致内存分配器提前预留了大量内存块，而这些块可能无法被后续的分配请求复用，从而形成外部碎片。

以本次事件中的 user_behavior_digest 为例，该 Hash 的 field 数量高达 9000 万，且每个 field 的值存储的是 JSON 编码的用户行为摘要。这种高密度、非均匀分布的数据结构导致 Redis 在分配内存时频繁请求不同大小的内存块。当 Redis 通过预分配策略预留了大量小内存块后，后续分配的字段可能需要更大的内存块，导致原有的小块内存无法被复用，最终形成外部碎片。

此外，user_behavior_digest 的内存占用长期处于高位，且未设置 TTL，导致 Redis 无法通过自然淘汰机制释放内存。这种情况下，预分配策略可能进一步加剧内存碎片化问题，因为内存分配器无法及时回收不再使用的内存块，导致内存碎片持续累积。

预分配策略的优化方向

为缓解预分配带来的碎片化问题，可以采取以下优化策略：

1. 动态调整 slab 分配粒度：
   jemalloc 的 slab-size 参数决定了内存分配器在分配内存时的最小单位。通过动态调整 slab-size，可以优化内存块的复用效率。例如，在处理大量小对象（如 user_behavior_digest 的 field）时，可以适当减小 slab-size，以减少因内存块大小不匹配导致的外部碎片。然而，过小的 slab-size 可能导致频繁的内存分配和释放，增加 CPU 开销，需根据实际场景权衡。

2. 启用内存碎片回收机制：
   某些 jemalloc 版本支持内存碎片回收（Memory Fragmentation Recovery），通过定期清理无法复用的内存碎片，减少碎片化对内存利用率的影响。在 Redis 的配置中，可以通过设置 --jemalloc 参数启用这一功能，例如：

   --jemalloc=slab-size=4096,fragmentation-recovery=on
   

   这一配置将 slab 分配粒度设置为 4096 字节，并启用碎片回收机制，有助于减少因频繁分配和释放导致的碎片化。

3. 限制单个 Key 的内存占用：
   对于类似 user_behavior_digest 这样的高密度 Hash，可以通过拆分或分片策略减少单个 Key 的内存占用。例如，将用户行为数据按时间窗口或用户 ID 进行分片，分散到多个 Hash 中，避免单个 Hash 占用过大的内存空间。这一策略不仅有助于缓解内存碎片化，还能提升 Redis 的并发性能。

4. 结合内存监控与动态调整：
   通过 MEMORY USAGE 和 INFO memory 命令实时监控 Redis 的内存使用情况，并结合 memfrag 参数分析内存碎片化程度。当检测到碎片化严重时，可以动态调整预分配策略或触发内存回收操作。例如，在 INFO memory 中，memfrag 参数表示内存分配器中未被使用的内存碎片总量，若该值持续增长，可能意味着需要优化预分配策略或调整内存淘汰策略。

预分配与业务场景的适配性

内存预分配策略的优化需结合具体业务场景进行适配。例如，在高并发、低延迟的场景中，预分配策略可能更有利于提升性能，但在内存密集型场景中，过度预分配可能导致内存浪费和碎片化问题。因此，建议在实际部署中通过以下方式实现动态适配：

• 分阶段预分配：根据业务流量的周期性波动，分阶段调整预分配策略。例如，在业务高峰期增加预分配内存，而在低谷期减少预分配量，以平衡内存利用率和碎片化风险。
• 模块化存储设计：对于高密度数据结构（如 user_behavior_digest），采用模块化存储设计（如 RedisJSON、RedisGraph 等），利用 Redis 的模块化功能优化内存分配和碎片化管理。
• 监控与预警机制：通过实时监控 Redis 的内存使用情况和碎片化程度，设置动态预警阈值。当检测到碎片化达到临界值时，自动触发内存回收或调整预分配策略，避免内存危机。

通过优化内存预分配策略，可以有效缓解 Redis 内存碎片化问题，提升内存利用率并降低缓存雪崩的风险。在本次事件中，user_behavior_digest 的内存占用异常本质上是预分配策略与碎片化问题的叠加效应，而通过针对性的优化措施，可以避免类似问题的再次发生。