调大 lfu-log-factor 能缓解突发流量导致的计数器膨胀，因其降低低频键计数器增长概率，避免冷数据被短时刷量推高而挤占真正热键。
为什么调大 lfu-log-factor 能缓解突发流量导致的计数器膨胀
Redis 的 LFU 计数器不是每次访问都 +1，而是按概率递增：当前计数器值越低、lfu-log-factor 越小，增长越快；反之，调大它会让高频键的计数器“更难涨上去”。这本质上是用对数曲线模拟真实访问热度，避免短时刷量（比如秒杀预热、爬虫扫键）把冷数据计数器瞬间拉高，挤掉真正长期高频的热键。
lfu-log-factor 值怎么选：看你的访问峰谷比和业务容忍度
默认值 10 适合大多数缓存场景（约 100 万次访问才到上限 255）。但如果你遇到以下情况，该调了：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 秒杀或促销期间出现毫秒级密集访问，
evicted_keys暴增且命中率骤降 → 尝试设为20或30 - 监控发现大量 key 的
logc在 10–20 区间扎堆，淘汰缺乏区分度 → 可降到5，让低频键更快暴露 - 用
OBJECT FREQ查过几个热键，发现它们的计数器在流量平稳后仍卡在高位不回落 → 说明衰减没跟上增长，优先调大lfu-log-factor而非只调lfu-decay-time
调参后必须验证的两件事
光改配置不看效果等于白调。重点盯这两个指标：
- 执行
CONFIG GET lfu-log-factor确认已生效（注意：它不支持CONFIG REWRITE持久化，需手动写入redis.conf） - 用
INFO stats观察evicted_keys和keyspace_hits的小时级趋势 —— 如果淘汰量下降但命中率没升，可能是lfu-log-factor过大，把中频键也压得太低了 - 抽样几个典型 key，用
OBJECT FREQ对比调参前后计数器变化节奏（例如同样 1000 次请求，调前logc从 5→18，调后仅 5→9，就说明起效了）
容易被忽略的副作用：衰减逻辑其实依赖计数器初始值
lfu-log-factor 不只影响增长，还间接影响衰减起点。因为 Redis 内部用 logc - LFU_INIT_VAL（默认 5）算基础差值，再代入概率公式。这意味着：
- 你把
lfu-log-factor从 10 改成 100，不只是让增长变慢，还让低频键（logc接近 5）的衰减触发更敏感 - 如果同时调高
lfu-decay-time（比如到 10），但lfu-log-factor没动，旧键可能长期滞留 —— 这种组合容易掩盖真实热点变化 - 没有绝对“最优值”，它必须和你的
maxmemory-samples（抽样数）、实际 QPS 分布一起看
