内存管理的艺术：为何 volatile-lru 是秒杀系统的定海神针
在 Redis 的众多内存淘汰策略中，allkeys-lru 常常被视为纯缓存场景下的“万金油”首选。然而，在秒杀系统这种极端高压且业务逻辑复杂的场景下，如果将 Redis 视为一个“半缓存半持久化”的混合存储引擎，那么 volatile-lru 才是真正体现架构师权衡智慧的精准之选。（看主页）
秒杀系统与普通电商业务最大的不同，在于其数据具有极强的“冷热分层”与“时效性”特征。在一个典型的秒杀 Redis 实例中，我们往往同时存储着两类截然不同的数据：一类是库存、活动状态等绝对不能丢失的“核心数据”；另一类则是用户会话、临时黑名单、限流计数器等随时可以丢弃的“临时数据”。
如果盲目使用 allkeys-lru，Redis 会在内存吃紧时，从全库所有键中无情地淘汰掉“最近最少使用”的数据。这就带来了一个致命的隐患：那些没有设置过期时间的核心库存数据，仅仅因为短时间内访问频率稍低（例如活动刚开始的冷门商品），就可能被误伤淘汰。一旦核心业务数据被清空，不仅会导致缓存击穿直接打垮数据库，甚至可能引发严重的超卖事故。
而 volatile-lru 的精髓，恰恰在于它引入了“过期时间（TTL）”作为一道安全防火墙。它明确告诉 Redis：只有那些设置了过期时间的键，才有资格参与 LRU（最近最少使用）的淘汰游戏。这为我们提供了一种极其优雅的数据隔离手段——对于库存等核心数据，我们坚决不设置过期时间，让它们永远处于 volatile-lru 的淘汰范围之外，从而得到绝对的保护；而对于海量的临时数据，我们为其设置合理的 TTL，当内存告急时，Redis 会优先在这些“注定要消失”的数据中，淘汰掉那些近期未被访问的键。
这种策略完美契合了秒杀系统“保核心、弃边缘”的生存法则。它既利用了 LRU 算法保留热点临时数据的优势，又通过 TTL 的筛选机制，为核心业务数据撑起了一把保护伞。
当然，选择 volatile-lru 也意味着架构师必须承担起更精细化的运维责任。你必须确保那些可被淘汰的数据都被正确设置了 TTL，否则它们就会变成无法清理的“内存僵尸”，最终导致 Redis 内存溢出（OOM）并拒绝写入。但正是这种对数据生命周期的精准把控，才是一个成熟秒杀系统区别于普通缓存应用的关键所在。
在技术的选型中，从来没有绝对完美的策略，只有最契合场景的取舍。volatile-lru 在秒杀系统中的成功应用，本质上是一场关于数据价值与内存边界的精准博弈，它让我们在面对高并发洪流时，依然能够从容地守住业务的底线。