标准答案
- 先按业务判断可接受的旧数据窗口：商品展示可以容忍分钟级旧值，库存、风控状态和登录态通常需要更短窗口或主动失效。
- 再看数据变化来源和频率：频繁变更且难以准确失效的数据不适合长 TTL；稳定字典数据可以更长，并在发布时使用版本前缀整体切换。
- 最后结合内存容量、命中率和回源承载力设置 TTL；TTL 太短会放大数据库压力，太长会使陈旧数据和清理成本持续累积。
- 高并发 Key 应加入合理随机抖动，避免大量相近 TTL 在同一时刻失效；但抖动范围不能大到破坏业务时效承诺。
题目解析
统一的“缓存五分钟”配置看似简单，实际把不同一致性要求混在一起。TTL 应当是数据契约的一部分，至少要能解释对象为何允许这个时间窗口的陈旧。
TTL 不是唯一失效机制。更新事件、显式删除、版本号和逻辑过期可以与 TTL 组合使用，分别解决实时失效、整体切换和热点保护。
常见误区
- 为了提高命中率无限延长 TTL，结果用户长期看到旧权限、旧价格或已删除数据。
- 只根据 Redis 内存大小设置 TTL，完全没有业务时效和回源能力依据。