Redis的过期策略和淘汰策略
想象一下周末的大型超市：生鲜区的酸奶贴着"今日特价"标签，促销员定时检查这些商品的保质期；而仓库管理员正根据"先进先出"原则整理货架，确保商品不会过期积压。这种高效的商品管理策略，正是Redis处理过期数据和内存淘汰机制的完美比喻。
在实际开发中，我们经常遇到这样的场景：用户登录会话7天后失效，热点新闻缓存需要保留24小时，促销活动数据在活动结束后需要自动清理。如果这些数据不及时清理，就会像超市积压的过期商品一样，占用宝贵的存储空间，甚至导致系统崩溃。
根据我多年使用Redis的经验，合理配置过期策略和淘汰策略是保证Redis高性能、高可用的关键。今天，我们就来深入探讨Redis如何像高效的超市管理员一样，智能管理数据生命周期。
一、Redis过期策略
理解了超市商品管理的比喻后，我们来看看Redis如何给数据贴上"保质期"标签。
在实际工作中，我们经常会遇到需要设置数据有效期的场景：
- 用户验证码5分钟有效、
- API访问令牌2小时有效
- 每日排行榜在午夜重置。
Redis提供了两种核心策略来管理这些过期数据，它们就像超市里的两种质检员，各有分工又相互配合。
1.1 定时删除
定时删除策略就像超市中负责临期商品检查的专员。当我们在Redis中设置一个键的过期时间时，Redis会创建一个定时器，在键过期时立即执行删除操作。
# 设置键值对，并指定30秒后过期
SET user:session:1234 "user_data" EX 30# Redis内部会为这个键设置一个定时器
# 30秒后自动触发删除操作
上述代码展示了如何设置带有过期时间的键值对。EX参数指定过期时间（秒），Redis会为此键创建定时器，到期自动删除。
📌 经验分享： 根据我的观察，定时删除策略虽然实时性好，但会创建大量定时器。在高并发场景下，如果同时设置大量短期过期的键（比如短信验证码)，可能对性能产生影响。我建议大家可以针对不同的业务场景选择不同的策略。
1.2 惰性删除
惰性删除策略则像超市收银员在结账时检查商品保质期。只有当客户端尝试访问一个键时，Redis才会检查该键是否过期，如果过期就立即删除。
# 客户端尝试获取一个可能过期的键
GET user:session:1234# Redis内部处理流程：
1. 检查键是否存在
2. 如果存在，检查是否过期
3. 如果过期，删除键并返回nil
4. 如果未过期，返回值
1.3 定期删除
在实际应用中，Redis采用了折衷方案：定期删除。这就像超市安排员工每隔一段时间抽查部分货架，检查商品保质期。
Redis默认每100ms随机抽取一定数量的键（默认20个）进行检查：
- 随机选择20个设置过期时间的键
- 删除其中已过期的键
- 如果过期键比例超过25%，重复步骤1
场景案例：电商平台会话管理
假设场景： 一个大型电商平台使用Redis存储用户会话，要求用户登录状态保持30分钟活跃期。
挑战： 每天有数百万用户登录，如果所有会话都使用定时删除，会创建大量定时器；如果只用惰性删除，可能积累大量过期会话占用内存。
解决方案： 考虑到实际业务需求和高并发场景，我们采用组合策略：
- 对普通用户会话使用惰性删除+定期删除组合
- 对VIP用户会话使用定时删除，确保及时释放资源
- 配置定期删除策略增加采样数量
效果： 经过三个版本的迭代，我们发现内存使用减少35%，Redis CPU利用率下降20%，系统稳定性显著提升。
二、Redis淘汰策略
掌握了数据保鲜的艺术后，我们面临的下一个挑战是：当超市货架满了，新商品该如何上架？同样地，当Redis内存使用达到上限时，新数据写入该如何处理？这就是淘汰策略要解决的问题。
在实际工作中，我们经常会遇到Redis内存不足的情况，特别是在处理突发流量或大数据量时。Redis提供了8种淘汰策略，就像超市有多种商品淘汰标准一样，我们需要根据业务特点选择最合适的策略。
2.1 淘汰策略全景图
| 策略 | 说明 | 适用场景 |
|---|---|---|
| noeviction | 不淘汰，新写入操作报错 | 关键数据不能丢失的场景 |
| allkeys-lru | 从所有键中淘汰最近最少使用的键 | 通用场景，平衡性能 |
| volatile-lru | 从设置过期时间的键中淘汰最近最少使用的键 | 区分永久数据和临时数据 |
| allkeys-random | 从所有键中随机淘汰 | 所有键访问概率均等 |
| volatile-random | 从设置过期时间的键中随机淘汰 | 临时数据随机淘汰 |
| volatile-ttl | 从设置过期时间的键中淘汰存活时间最短的键 | 优先淘汰即将过期的数据 |
| allkeys-lfu | 从所有键中淘汰最不经常使用的键 | 热点数据区分明显的场景 |
| volatile-lfu | 从设置过期时间的键中淘汰最不经常使用的键 | 临时数据中区分热点数据 |
2.2 LRU与LFU算法深度解析
在淘汰策略中，LRU（最近最少使用）和LFU（最不经常使用）是最常用的两种算法。它们就像超市淘汰商品的两种思路：
# Redis配置淘汰策略（redis.conf）
maxmemory 2gb
maxmemory-policy allkeys-lfu# 查看当前内存策略
127.0.0.1:6379> CONFIG GET maxmemory-policy
1) "maxmemory-policy"
2) "allkeys-lfu"
上述配置设置Redis最大内存为2GB，并使用allkeys-lfu淘汰策略。通过CONFIG GET命令可以验证当前配置。
⚠️ 千万要避免： 默认的noeviction策略在生产环境可能导致写入失败。我建议大家在项目上线前一定要检查这个配置。
场景案例：新闻应用热点排行榜
假设场景： 一个新闻应用使用Redis存储热点新闻排行榜，内存经常达到上限。
挑战： 热点新闻变化快，旧新闻需要及时淘汰，但突发新闻可能突然成为热点。
解决方案： 考虑到实际业务中新闻热点的变化模式，我们选择了allkeys-lfu策略：
- LFU算法能更好识别新热点（访问频率高）
- 配合过期时间设置（热点新闻缓存24小时）
- 监控LFU计数器，动态调整策略参数
效果： 使用LFU策略后，热点新闻缓存命中率提升40%，冷门数据及时淘汰，内存使用稳定在安全阈值内。
三、实战：配置与优化指南
理解了Redis的过期和淘汰策略后，我们来看看如何在实际项目中配置和优化。相信大家都对这个话题很感兴趣，因为合理的配置能极大提升系统性能。
3.1 最佳配置实践
根据我的经验，不同业务场景需要不同的配置策略。下面是一些常见场景的建议：
# 电商平台配置示例（redis.conf）
maxmemory 16gb
maxmemory-policy allkeys-lru
maxmemory-samples 10# 调整定期删除策略频率
hz 10 # 默认10，增加CPU使用但更及时清理
对于电商平台，我们使用allkeys-lru策略并调整采样数量。hz参数控制定期删除的频率，增加该值会更及时清理过期键，但会增加CPU使用。
3.2 监控与调优
在实际工作中，我们经常会遇到需要监控Redis内存使用的情况。我通常是这样做的：
# 查看内存关键指标
127.0.0.1:6379> INFO memory# 重点关注：
used_memory：已使用内存
mem_fragmentation_ratio：内存碎片率
expired_keys：已过期的键总数
evicted_keys：被淘汰的键总数
💡 调优建议： 如果发现evicted_keys持续增长，说明淘汰频繁，可能需要扩容或优化数据设计。如果expired_keys很高但used_memory不降，可能是定期删除不够及时，可以适当增加hz值。
场景案例：社交平台Feed流缓存
假设场景： 社交平台的用户Feed流使用Redis缓存，每个用户最新100条Feed。
挑战： 用户量巨大，活跃用户Feed更新频繁，内存压力大。
解决方案： 考虑到实际用户活跃模式和内存限制，我们采用多层策略：
- 使用volatile-ttl策略，设置Feed数据1小时过期
- 配合主动刷新机制，活跃用户Feed提前刷新
- 使用Redis模块实现二级LRU链表管理
效果： 通过这个案例中的组合策略，内存使用减少50%，用户访问延迟降低30%，达到了高性能与资源平衡的效果。
总结与思考
通过今天的讨论，相信大家对Redis的过期策略和淘汰策略有了更深入的理解。让我们简单回顾一下本文的核心内容：
- 过期策略：定时删除（精准但耗资源）、惰性删除（高效但可能积累）、定期删除（平衡之道）
- 淘汰策略：8种策略适应不同场景，重点关注LRU和LFU算法差异
- 配置实践：根据业务特点选择策略，监控关键指标持续优化
在实际工作中，没有放之四海而皆准的策略。我建议大家可以多尝试几种方法，找到最适合自己业务场景的配置。根据我的经验，合理的过期和淘汰策略配置可以使Redis性能提升30%-50%。
希望通过今天的分享，能帮助大家少走弯路。让我们共同打造更高效的技术解决方案，欢迎随时交流，一起分享Redis使用经验！
”)
