LFU衰减需满足时间条件才触发，非实时发生；默认lfu_decay_time为1分钟，仅在key被访问或淘汰采样时顺带衰减，长期未访问的key不会自动衰减。
怎么看LFU衰减是否生效
Redis的LFU衰减不是实时发生的，它依赖后台定时任务周期性扫描并递减计数器。如果你发现某个key访问后logc没变少，或者“冷掉”的key迟迟不被淘汰，大概率是衰减根本没触发——不是bug，是设计如此。
-
lfu_decay_time默认为1分钟，意味着：只有距离上一次访问满1分钟，才会在下一次访问时（或后台周期检查时）执行-1操作 - 衰减只发生在key被访问时的前置步骤（即每次
lookupKey前先调用LFUDecrAndReturn），不是独立线程每秒轮询 - 如果key长期无人访问，它的
logc不会自动衰减；必须等下次访问或淘汰采样时才顺带处理 - 验证方法：用
OBJECT FREQ查两次值，中间隔2分钟再访问一次，观察是否从10→8（假设初始为10且lfu_decay_time=1）
lfu_decay_time调小就一定更灵敏？
不是。把lfu_decay_time从60秒改成10秒，看似衰减更快，但实际会放大LFU的“抖动”风险：高频key可能因多次衰减+概率计数未命中，导致logc虚低，误判为冷数据。
- 衰减越频繁，
logc越容易被“削平”，削弱LFU识别长期热点的能力 - 极端情况（如设为1）：高并发下多个线程同时对同一key做衰减和+1，可能因竞争导致计数器震荡
- 官方建议保持默认1分钟；仅当业务明确存在“小时级热度衰减需求”（比如新闻类缓存）才考虑下调，且应配合
maxmemory-samples调大到10以上以提升采样稳定性
为什么OBJECT FREQ返回值总卡在255不动
这是LFU概率计数机制的自然结果，不是溢出错误。Redis用8位存储logc，上限就是255；但更重要的是，越接近255，后续+1的概率越低——这正是对数增长设计的本意。
- 公式是：
R 才+1；当<code>old_counter = 254、lfu_log_factor = 10时，阈值P=2541，而R∈[0,1)，永远不满足条件 → 停滞 - 这不是缺陷，是防止头部key垄断缓存：一个视频被点播10万次，和被点播255次，在LFU眼里“热度饱和”，后续靠时间衰减和采样公平性来区分
- 若真需更高精度，说明LFU不适合该场景——应换用
allkeys-lru或自建分层缓存
衰减时间和上次访问时间戳（ldt）怎么共存
Redis把24位lru字段拆成两段复用：16bit last decay time + 8bit counter。所以ldt不是完整时间戳，而是距上次衰减的“相对分钟数”编码值。
- 每次衰减时，Redis用当前时间（秒级）除以
lfu_decay_time取整，写入高16位；这意味着：如果lfu_decay_time=1，那ldt就是“距Unix epoch多少分钟”，精度约45天 - 计算衰减量时，并非直接用
now - ldt，而是(now / lfu_decay_time) - (ldt)，避免浮点误差 - 这个设计让单个字段承载两个维度，但代价是：无法还原真实访问时间，也无法跨实例比对“哪个key更老”
Redis的LFU衰减机制本质是“懒执行+概率+位压缩”的组合解法，不是精确计时器。真正容易被忽略的，是它和访问路径强耦合——没有访问，就没有衰减，也没有重算。
