Redis 内存被打满之后，我翻遍源码总结的这 7 条保命经验

兄弟们，你们见过 Redis 内存满了之后，整个系统慢慢“窒息”的样子吗？上周三下午 3 点，业务高峰期，监控突然报警——Redis 内存使用率飙到 99.8%，新的写入请求全部失败，缓存命中率从 95% 跌到 30%，数据库瞬间被打爆。

我冲到工位，第一反应是“谁写了 BigKey？”，第二反应是“淘汰策略怎么没生效？”。那天晚上我翻了一整晚源码和监控，才发现我们对 Redis 内存管理的理解，还停留在“配个 maxmemory 就完事”的程度。今天就把这次翻车的完整复盘和 7 条保命经验分享出来。

一、事故还原：内存是怎么被打满的？

我们的 Redis 实例配置了 maxmemory=12GB（物理内存 16GB），淘汰策略用的是默认的 noeviction——内存满了之后拒绝所有写入请求。

活动开始后，大量新数据写入，同时一批设置了 7 天过期时间的 Key 集中过期。但过期 Key 并没有被立即删除，而是堆积在内存中。到下午 3 点，used_memory 达到 12GB 阈值，Redis 开始拒绝写入。业务方报错、缓存失效、数据库被打爆，整个链路雪崩。

根因：我们对 Redis 过期策略和淘汰策略的理解有严重偏差。

监控数据：

# redis-cli INFO memory 输出
used_memory: 12884901888 (12.0GB)
used_memory_human: 12.00G
maxmemory: 12884901888 (12.0GB)
maxmemory_human: 12.00G
mem_fragmentation_ratio: 1.85  ← 碎片率 85%！
evicted_keys: 0                ← 淘汰策略根本没触发

内存碎片率 1.85 意味着有 85% 的额外内存被浪费。过期 Key 没有被及时清理，碎片率飙升，最终把内存撑爆了。

二、过期策略：为什么过期 Key 还在占内存？

很多人以为设置了 TTL，Key 过期后内存就自动释放了。大错特错。

Redis 的过期 Key 删除采用两种策略配合：惰性删除 + 定期删除。

2.1 惰性删除

原理：只有在访问一个 Key 时，Redis 才会检查它是否过期。如果过期，立即删除。

优点：CPU 友好，不额外消耗资源。

缺点：如果过期 Key 再也不被访问，就会永远占用内存。

// Redis 源码中惰性删除的核心逻辑（简化）
int expireIfNeeded(redisDb *db, robj *key) {
    // 检查 Key 是否过期
    if (!keyIsExpired(db, key)) return 0;
    // 过期则删除，并通知从库和 AOF
    deleteExpiredKeyAndPropagate(db, key);
    return 1;
}

2.2 定期删除

原理：Redis 默认每隔 100ms 执行一次后台任务 serverCron（由 hz 参数控制频率，默认 10，即每秒执行 10 次）。这个任务会启动 activeExpireCycle 函数，采样式地清理过期 Key。

关键参数：

• hz：serverCron 的执行频率，默认 10（每秒执行 10 次）

• 每次扫描 expires 字典中最多 20 个 Key

• 如果删除比例超过 10%，继续扫描下一批

关键认知：定期删除不是全量扫描所有 Key，而是有策略地抽样，在 CPU 耗时和内存释放之间做平衡。

完整的执行流程

 

 

关键步骤拆解

第一步：按 Hash 桶维度取样

Redis 不是从 expires 字典中随机挑 20 个 Key，而是按 hash 桶的顺序扫描。如果当前桶内有 15 个 Key，就全部检查；如果桶是空的，跳到下一个非空桶。这保证了扫描的高效性。

第二步：最多扫描 20 个 Key

每轮扫描最多处理 20 个 Key（由 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 宏定义控制）。这个数字是为了控制单次扫描的 CPU 耗时。

第三步：删除已过期的 Key

找到已过期的 Key 直接删除，同时记录删除数量。

第四步：删除比例超过 10% 则继续

如果本轮删除的 Key 占扫描总数的比例超过 10%（由 ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC 控制），说明当前 expires 字典里过期 Key 比例较高，需要继续下一轮扫描，直到删除比例低于 10%。

第五步：循环次数限制与超时保护

• 每轮扫描最多循环 16 次（ACTIVE_EXPIRE_CYCLE_SLOW_LOOPS）

• 16 次之后会检查总耗时是否超过 1ms（ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC 换算），如果超时则直接返回，避免占用主线程太久

核心设计哲学：这是一个有上限的尽力而为机制。通过“删除比例 > 10% 继续”的反馈调节，确保在有大量过期 Key 时能持续清理；通过“16 次循环 + 1ms 超时”的保护机制，确保不会因为清理过期 Key 而阻塞正常请求。

为什么定期删除不保证清理所有过期 Key？

这种设计的取舍非常清晰：

• 如果每次扫描全量 expires 字典，在 Key 数量大的情况下会长时间阻塞 Redis

• 单线程模型下，任何耗时操作都会影响所有请求的延迟

• 所以 Redis 选择“少量多次 + 反馈调节 + 超时保护”的策略

过期策略总结

 

2.3 两种策略配合的效果

 

策略	触发时机	优点	缺点
惰性删除	访问 Key 时	CPU 零开销	过期 Key 可能永不被删除
定期删除	每 100ms 后台扫描	主动清理过期 Key	CPU 有开销，抽样可能漏删

说白了，Redis 的过期策略是一种“尽力而为”的机制，不保证过期 Key 被立即删除。 这就是我们翻车的第一个原因——大量过期 Key 堆积，内存被撑爆。

关于过期删除的常见误区

 

误区	真相
“设置 TTL 后到期自动删除”	Redis 不会主动删除所有过期 Key，惰性+定期配合
“定期删除会全量扫描”	定期删除只按 hash 桶抽样扫描，最多 20 个 Key
“删除比例超过 10% 会一直删到完”	循环 16 次后会检查耗时，超过 1ms 就返回
“过期 Key 不占内存”	未被删除的过期 Key 仍然占用内存

三、淘汰策略：内存满了怎么办？

当 maxmemory 达到上限时，Redis 会根据 maxmemory-policy 配置决定淘汰哪些数据。

3.1 八种淘汰策略

 

策略	淘汰范围	淘汰算法
noeviction（默认）	不淘汰	拒绝写入，返回错误
allkeys-lru	所有 Key	淘汰最近最少使用的
allkeys-lfu	所有 Key	淘汰访问频率最低的
allkeys-random	所有 Key	随机淘汰
volatile-lru	有过期时间的 Key	淘汰最近最少使用的
volatile-lfu	有过期时间的 Key	淘汰访问频率最低的
volatile-random	有过期时间的 Key	随机淘汰
volatile-ttl	有过期时间的 Key	淘汰剩余 TTL 最短的

3.2 近似 LRU vs 精确 LRU

Redis 没有使用严格的 LRU 算法，而是采用近似 LRU：

1. 每次淘汰时，随机选出 maxmemory-samples 个 Key（默认 5 个）

2. 从这些样本中选出最久未被访问的 Key 淘汰

3. 样本数越大，淘汰越精确，但 CPU 开销也越大

 

3.3 我们翻车的第二个原因：用了 noeviction

noeviction 是默认策略，但它不会淘汰任何 Key。内存满了之后直接拒绝写入。

# 配置建议：生产环境千万别用 noeviction
maxmemory-policy allkeys-lru   # 大多数场景推荐
# 或
maxmemory-policy volatile-lru  # 只淘汰有过期时间的 Key

修改后效果：淘汰策略生效后，内存使用率稳定在 80% 左右，不再打满。

四、内存碎片：被忽略的“隐形杀手”

删除大量 Key 后，used_memory 下降了，但 used_memory_rss（操作系统看到的物理内存）可能纹丝不动。

4.1 碎片是怎么产生的？

Redis 使用 jemalloc 内存分配器。频繁的写入和删除会导致内存块被拆分成不连续的小块，无法被有效利用。

4.2 如何判断碎片是否严重？

redis-cli INFO memory | grep mem_fragmentation_ratio

• mem_fragmentation_ratio 在 1~1.5 之间：正常

• mem_fragmentation_ratio 在 1.5~2 之间：需要关注

• mem_fragmentation_ratio 超过 2：严重，必须处理

我们当时的碎片率是 1.85，属于严重级别。

4.3 如何清理碎片？

方案一：主动碎片整理（Redis 4.0+）

# 开启主动碎片整理
config set activedefrag yes

配置参数：

• active-defrag-threshold-lower 10：碎片率超过 10% 时启动整理

• active-defrag-cycle-min 25：CPU 最低占用 25%

• active-defrag-cycle-max 75：CPU 最高占用 75%

方案二：重启实例（最彻底，但需要停服）

 

五、BigKey：Redis 性能的“头号杀手”

BigKey 是我心目中排名前三的 Redis 杀手。BigKey 最大的问题不是内存，而是：

• 网络传输慢：一个 10MB 的 Key，读一次就要传输 10MB 数据

• 阻塞其他请求：Redis 单线程执行命令，BigKey 操作会卡住所有后续请求

• 集群数据倾斜：BigKey 所在的节点内存远高于其他节点

• 迁移/扩容巨慢：集群 rehash 时迁移 BigKey 耗时极长

5.1 如何发现 BigKey？

# 使用 redis-cli 扫描 BigKey
redis-cli --bigkeys

# 或使用 MEMORY USAGE 命令查看单个 Key 的内存占用
MEMORY USAGE mykey

--bigkeys 的局限性：它会遍历所有 Key，生产环境慎用，建议在低峰期执行。

5.2 如何治理 BigKey？

 

数据类型	治理方案
String 大 Value	压缩后存储（GZIP），或拆分成多个小 Key
Hash 大 Field	拆分成多个 Hash，按业务维度分片
List 长列表	用 LTRIM 限制长度，或分页存储
Set/ZSet 大集合	按业务维度拆分

六、SCAN 遍历：不用 keys * 也能优雅遍历

KEYS * 命令会阻塞 Redis，在数据量大的情况下可能导致服务卡顿数秒甚至数分钟。

6.1 SCAN 的核心原理

SCAN 通过游标（cursor） 分段遍历，每次只返回一小部分 Key。

# 第一次扫描，游标从 0 开始
SCAN 0 MATCH user:* COUNT 100

# 返回结果包含下一个游标和本次匹配的 Key
1) "38"   # 下一个游标
2) 1) "user:1001"
   2) "user:1002"
   ...

# 继续用返回的游标迭代
SCAN 38 MATCH user:* COUNT 100

6.2 SCAN 的遍历顺序：高位进位加法

Redis 的 SCAN 采用了高位进位加法遍历哈希表，而不是从 0 到 N 顺序遍历。

为什么这样设计？ 在字典扩容/缩容时，保证同一个 Key 不会被重复遍历，也不会被遗漏。

 

 

6.3 SCAN vs KEYS

 

命令	阻塞性	返回完整性	适用场景
KEYS	阻塞	一次性返回全部	禁止生产环境使用
SCAN	非阻塞	多次迭代，可能有重复	生产环境遍历 Key

SCAN 的注意事项：

• 每次返回的 Key 数量不固定，COUNT 只是提示

• 可能会有重复 Key，客户端需要自己去重

• 遍历期间如果有 Key 被删除，可能遍历不到

七、内存优化实战：7 条保命经验

7.1 maxmemory 设置

建议：设置为物理内存的 70%~80%。剩余内存留给操作系统和 AOF/RDB 子进程。

# 32GB 物理内存
maxmemory 24gb

7.2 淘汰策略选择

 

场景	推荐策略
缓存场景（可丢失）	allkeys-lru
缓存 + 持久数据混合	volatile-lru
热点数据明确	allkeys-lfu
大部分场景	千万不要用 noeviction

7.3 监控指标

每天巡检以下指标：

redis-cli INFO memory | grep -E "used_memory_human|maxmemory|mem_fragmentation_ratio|evicted_keys"

• used_memory_human：当前使用内存

• mem_fragmentation_ratio：碎片率，超过 1.5 需要关注

• evicted_keys：被淘汰的 Key 数量，突增说明内存不足

7.4 过期时间设计

• 给 Key 设置合理的 TTL，不要永久保留

• 大量 Key 的过期时间加随机偏移，避免集中过期

// 过期时间加随机偏移，防雪崩
int baseExpire = 3600;
int randomOffset = new Random().nextInt(600);
int actualExpire = baseExpire + randomOffset;
redis.setex(key, actualExpire, value);

7.5 主动碎片整理

config set activedefrag yes
config set active-defrag-threshold-lower 10
config set active-defrag-cycle-min 25

7.6 数据结构优化

• 小 Hash 用 ziplist：hash-max-ziplist-entries 512

• 小 ZSet 用 ziplist：zset-max-ziplist-entries 128

• String 尽量用整数：整数存储比字符串省内存

Redis 7.4 和 8.0 对 Hash 和 Sorted Set 的内存占用有显著优化，Hash 最多可降低 16.7%，ZSet 最多可降低 30.5%。

7.7 定期巡检 BigKey

# 低峰期执行
redis-cli --bigkeys -i 0.1  # -i 0.1 表示每扫描 100 个 Key 暂停 0.1 秒

八、总结：7 条保命经验

1. 过期 Key 不会自动删除——惰性删除 + 定期删除只是尽力而为

2. 千万别用 noeviction——内存满了会直接拒绝写入

3. 碎片率超过 1.5 就要处理——开启 activedefrag

4. BigKey 是头号杀手——--bigkeys 定期扫描，及时拆分

5. 生产环境禁用 KEYS *——用 SCAN 替代

6. maxmemory 设 70%~80%——留内存给操作系统和子进程

7. 过期时间加随机偏移——防止集中过期导致雪崩

兄弟们，你们在生产环境中遇到过 Redis 内存被打满的情况吗？是 BigKey 导致的还是淘汰策略没配好？评论区聊聊，我帮你们分析分析。