redis lfu计数器按需衰减而非定时衰减，衰减仅在key被访问或采样时触发，由lfu-decay-time控制检查时机；object freq返回当前logc快照，不包含待执行衰减；调小该值会引发震荡、误判与性能开销；衰减非原子操作，多线程下结果不可预测。
Redis的LFU计数器不是“自动定时衰减”，而是按需触发、延迟执行的——lfu-decay-time 控制的是衰减时机，不是衰减节奏。
lfu-decay-time 触发的是“检查窗口”，不是“倒计时器”
这个配置项（单位：分钟）只决定 Redis 什么时候“愿意去算一算该不该衰减”，而不是每过这么多分钟就无条件执行一次 -1。实际衰减发生在两个时刻之一：
- 某个 key 被访问前，Redis 会先检查：距它上一次访问是否已满
lfu-decay-time分钟？如果是，就立刻对它的logc执行一次右移 1 位（即除以 2 向下取整） - 内存淘汰采样时，如果该 key 被抽中，也会顺带做一次衰减检查
这意味着：一个长期没人碰的 key，它的 logc 值可能几个月都不变——直到下一次被访问或被采样到才衰减。这不是 bug，是设计上的懒加载优化。
为什么 OBJECT FREQ 查不到实时衰减值
OBJECT FREQ 返回的是当前内存里存着的那个 logc 快照，它不包含“未来待执行的衰减”。常见误解场景：
- 刚 set 一个 key，
OBJECT FREQ返回 5 → 正常，初始值就是 5 - 等了 2 分钟再查，还是 5 → 因为它没被访问/采样，衰减根本没触发
- 此时你 get 一下它，再查
OBJECT FREQ，大概率变成 2（5 >> 1）→ 衰减在 lookupKey 前就完成了
所以别用 OBJECT FREQ 判断“衰减是否准时”，而要用“访问前后对比”来验证逻辑是否生效。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
调小 lfu-decay-time 反而会让 LFU 更不准
把 lfu-decay-time 从默认 1 改成 0.1（6 秒），看似更灵敏，实则引入三重风险：
- 高频 key 在并发访问下可能被反复衰减+概率 +1，导致
logc震荡（比如 10 → 5 → 6 → 3） - 低频 key 的
logc被削得太快，刚涨到 3 就被衰减到 1，容易和真正冷数据混淆 - 衰减检查本身有开销，频繁触发会增加 lookupKey 的平均延迟（尤其在大 key 空间中）
官方建议保持默认 1 分钟；只有当你明确需要区分“小时级热度变化”（如突发新闻类缓存），且观察到 INFO memory 中 lfu_bypassed 显著升高时，才考虑下调，并同步调大 maxmemory-samples 至 10+ 提升采样稳定性。
衰减不是原子操作，竞争下结果不可预测
多个线程同时访问同一个 key 时，衰减和计数更新可能交错发生。例如：
- T1 线程读到
logc = 10，判断需衰减 → 执行10 >> 1 = 5 - T2 线程几乎同时读到
logc = 10，也执行衰减 → 再次写入5 - 接着 T1 概率 +1 成功 → 写入
6 - T2 也概率 +1 成功 → 写入
6（覆盖了 T1 的结果）
最终值仍是 6，但中间两次衰减只生效了一次。这种非确定性是 Redis LFU 在性能与精度之间做的主动取舍——它不保证单 key 的严格单调衰减，只保障整体淘汰倾向符合“低频优先”的统计规律。
真正难调的不是 lfu-decay-time 的数值，而是它和 lfu-log-factor 的协同效应：前者管“多久降一次”，后者管“每次降完还涨不涨得上去”。两者一起动，才会影响冷热边界的实际位置。
