Redis内存飙升的锅，原来是我没搞懂这个过期策略

Redis内存飙升的锅，原来是我没搞懂这个过期策略*

引言

最近在排查一个生产环境中的Redis内存使用问题时，发现了一个令人惊讶的现象：明明设置了大量key的过期时间，但Redis的内存占用却持续飙升，最终触发了OOM（Out Of Memory）报警。经过深入调查，发现问题的根源在于对Redis过期策略的误解。本文将详细剖析Redis的过期策略机制，解释为什么简单的TTL设置并不能保证内存及时释放，并给出实际场景中的优化建议。

Redis过期策略的基本原理

1. 过期时间的设置方式

Redis提供了四种设置key过期时间的方式：

redis 复制代码

EXPIRE key seconds
PEXPIRE key milliseconds
EXPIREAT key timestamp
PEXPIREAT key timestamp

这些命令看似简单，但背后的实现机制却相当复杂。关键在于理解Redis如何处理这些已过期的key。

2. 两种过期策略的结合

Redis实际上采用了被动过期 和主动过期两种策略的组合：

被动过期（惰性删除）：
- 当客户端尝试访问一个key时，Redis会检查该key是否已过期
- 如果已过期，则立即删除并返回nil
- 优点：对CPU友好，只在必要时执行删除操作
- 缺点：如果key永远不被访问，就会永远占用内存
主动过期（定期删除）：
- Redis会定期随机测试设置了TTL的key
- 删除所有发现的已过期key
- 具体实现通过redis.c中的activeExpireCycle()函数完成

深入分析主动过期机制

1. 主动过期的执行频率

Redis的主动过期不是传统意义上的定时任务，而是采用了一种自适应算法：

默认每秒运行10次（每100ms一次）
每次不会遍历所有key，而是采用抽样检查的方式
每次运行时：
- 从设置了过期时间的key字典中随机抽取20个key
- 删除其中已过期的key
- 如果发现超过25%的key已过期，则重复这个过程

2. 关键配置参数

redis 复制代码

# redis.conf中的相关配置
hz 10               # 每秒钟执行定期任务的次数，默认10
maxmemory-samples 5 # LRU和LFU算法中的采样数量

3. 为什么内存会飙升？

当以下情况同时发生时，就会出现内存问题：

大量key同时过期
这些key过期后不被访问（不被被动过期机制捕获）
主动过期策略来不及处理所有过期key
Redis实例接近最大内存限制

真实案例：电商促销活动的问题

1. 场景描述

某电商平台在大促期间：

使用Redis缓存商品库存信息
为每个商品设置30分钟过期时间
高峰期每秒写入约5000个新key

2. 出现的问题

内存使用量持续增长，超出预期
最终触发maxmemory限制
开始频繁淘汰未过期的key，影响业务

3. 根本原因

大量商品key同时过期（集中在整点和半点）
主动过期机制无法及时处理所有过期key
新写入的key持续占用内存

解决方案与最佳实践

1. 避免集中过期

错误做法*：

python 复制代码

# 所有key设置相同的TTL
redis_client.setex(key, 30*60, value)

正确做法*：

python 复制代码

# 添加随机抖动，分散过期时间
random_ttl = 30*60 + random.randint(0, 300)  # 30分钟±5分钟
redis_client.setex(key, random_ttl, value)

2. 合理配置内存策略

redis 复制代码

# redis.conf关键配置
maxmemory 16gb
maxmemory-policy allkeys-lru  # 根据业务需求选择

可选策略包括：

volatile-lru：只对设置了TTL的key使用LRU
allkeys-lru：对所有key使用LRU
volatile-ttl：优先删除剩余TTL短的key

3. 监控与告警

bash 复制代码

# 监控重要指标
redis-cli info memory | grep used_memory_human
redis-cli info stats | grep expired_keys

建议设置以下告警：

内存使用量 > 80%
每分钟过期key数量异常波动
被动过期与主动过期的比例失衡

高级优化技巧

1. 使用Redis模块

考虑使用Redis的RediSearch或RedisTimeSeries等模块，它们对内存管理有专门优化。

2. 分片策略

对于超大规模部署：

python 复制代码

# 使用一致性哈希分散key
from rediscluster import RedisCluster
startup_nodes = [{"host": "127.0.0.1", "port": "7000"}]
rc = RedisCluster(startup_nodes=startup_nodes, decode_responses=True)

3. Lua脚本批量处理

lua 复制代码

- - 批量设置随机TTL的脚本
for i, key in ipairs(KEYS) do
    local ttl = tonumber(ARGV[1]) + math.random(tonumber(ARGV[2]))
    redis.call('EXPIRE', key, ttl)
end

总结

Redis的内存管理看似简单，实则暗藏玄机。通过这次事故，我们深刻认识到：

单纯依赖TTL不能保证内存及时释放
必须理解主动过期和被动过期的协同工作机制
在大规模部署中，需要特别关注key的过期时间分布
合理的监控和告警机制是预防问题的关键

希望本文的经验能够帮助你避免类似的"内存陷阱"，让你的Redis实例运行得更加稳定高效。