Redis购物车淘汰策略详解

Redis电商购物车场景下，volatile-lru是兼顾数据安全与内存效率的优选淘汰策略——它精准聚焦于带TTL的临时购物车数据，避免误删用户登录态、商品主数据等核心永久信息，但绝非开箱即用：必须为每个购物车key显式设置并持续刷新过期时间（如每次增删商品后调用EXPIRE），否则未设TTL的key将永远滞留内存；其采样式淘汰机制虽保守可靠，却也带来小概率活跃购物车被误删、批量创建时退化为近似随机淘汰等风险，而allkeys-lfu因过度依赖访问频次反而违背购物车“按业务时效清理沉睡数据”的本质诉求，因此合理配置TTL+严谨刷新逻辑，才是释放volatile-lru真正价值的关键。

电商购物车场景下，volatile-lru 是合理但需谨慎使用的策略——它能清掉长期未操作的临时购物车数据，但前提是所有购物车 key 必须显式设置过期时间，否则根本不会被它淘汰。

为什么 volatile-lru 适合购物车，但不是开箱即用

购物车数据天然具备“临时性”：用户添加商品后若长时间不提交订单，该数据价值迅速衰减；而用户登录态、商品主数据等关键信息通常不设 TTL，需永久保留。此时 volatile-lru 的作用边界就非常清晰：只动“有保质期”的部分，不动核心数据。

但注意：volatile-lru 不会管你逻辑上“是不是购物车”，它只认 EXPIRE 或 SET ... EX 命令是否真的执行成功。如果漏设 TTL，对应 key 就永远卡在内存里，哪怕闲置半年也不会被这个策略碰一下。

• 必须为每个购物车 key 显式调用 EXPIRE cart:123 86400（如 24 小时）或使用 SET cart:123 "..." EX 86400
• 不能依赖“业务层认为它该过期”——Redis 不读你的注释，只看 ttl 返回值是否为正数
• 验证方式：任意一个购物车 key 执行 TTL cart:123，返回值应为正整数；若返回 -1（无过期）或 -2（已过期），说明配置失效

volatile-lru 在真实流量下的行为特征

它不是逐个扫描所有带 TTL 的 key 做精确 LRU 排序，而是采样淘汰：每次触发淘汰时，随机抽取 N 个带过期时间的 key（默认 N=5），从中挑出最近最少访问的那个删掉。这意味着：

• 高并发写入时，可能连续几次都抽中同一组冷 key，导致部分活跃购物车意外被删（概率低但存在）
• 如果大量购物车集中在同一秒内创建且 TTL 相同，volatile-lru 可能退化为近似随机淘汰——因为访问时间戳差异极小，采样难以区分
• 相比 allkeys-lru，它的内存释放更保守：若当前只有 10 个带 TTL 的 key，即使内存已满，最多只在这 10 个里删，不会动其他永久数据

容易踩的坑：TTL 设置时机与刷新逻辑

购物车常有“用户回来继续编辑”的需求，所以不能设完 TTL 就不管。必须在每次更新购物车（如增删商品、改数量）时同步刷新过期时间，否则用户刚加完商品，倒计时还在走，体验断裂。

• 错误做法：只在创建购物车时设一次 EXPIRE，后续所有操作都不 touch TTL
• 正确做法：每次 HSET cart:123 item_abc 2 后，紧跟 EXPIRE cart:123 86400；或者用 pipeline 批量发送
• 更稳妥方案：用 SET cart:123 "..." XX EX 86400（XX 表示仅当 key 存在时才设置），避免误覆盖其他业务 key
• 注意客户端连接中断导致命令未发全——建议服务端封装原子操作，而非依赖多条 Redis 命令顺序执行

对比 allkeys-lfu：为什么购物车通常不选它

allkeys-lfu 看起来更“智能”，能识别长期高频访问的 key。但它对购物车反而危险：一个用户反复加减同一商品，LFU 计数器会不断累加，导致这个购物车异常“顽固”，哪怕用户三天没登录，它仍比新用户的空购物车优先级高。而购物车的核心诉求是“及时清理沉睡数据”，不是“留住高频修改记录”。

真正需要 allkeys-lfu 的是商品详情页缓存、推荐结果缓存这类有长尾热度分布的场景。购物车的生命周期由业务规则驱动（如 24 小时自动过期），不是由访问频次决定的。

以上就是《Redis购物车淘汰策略详解》的详细内容，更多关于的资料请关注golang学习网公众号！