volatile-lru适合电商购物车场景，但需为每个购物车key显式设置TTL并定期刷新；它仅淘汰带过期时间的key，采样随机且保守，不适用于依赖访问频次的场景。
电商购物车场景下，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），从中挑出最近最少访问的那个删掉。这意味着：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 高并发写入时，可能连续几次都抽中同一组冷 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 小时自动过期），不是由访问频次决定的。
