volatile-lfu是Redis 4.0引入的仅针对带过期时间键的LFU淘汰策略，采用5-bit概率计数器、定时衰减和条件提升机制近似统计访问频率，并通过采样选出counter最小的key淘汰。
volatile-lfu 是 Redis 4.0 引入的内存淘汰策略，它只对设置了过期时间（TTL）的键生效，并基于“最近最少使用频率”（Least Frequently Used）进行淘汰——但不是简单统计总访问次数，而是用一种**概率性、近似、低内存开销的 LFU 实现**来估算访问频次。
LFU 的核心：用概率计数器替代精确计数
Redis 不为每个 key 单独维护一个递增计数器（那样内存和并发开销太大），而是采用：
- 5-bit 的访问频次寄存器（counter）：取值范围是 0–255，能表示大致热度等级，但不记录真实访问次数；
- 衰减机制（counter decay）：定期（默认每分钟）对所有 counter 按一定比例衰减（如右移或乘衰减因子），让旧的高频访问“热度”随时间自然下降，避免长期霸占高位；
- 概率提升规则：每次访问 key 时，并非无条件 +1，而是按当前 counter 值决定“是否提升”——counter 越高，再提升的概率越低（例如 counter=10 时提升概率可能为 0.1%，而 counter=1 时可能是 10%），防止突发流量瞬间拉高冷 key 的 counter。
volatile-lfu 的淘汰流程
当内存不足触发淘汰时，Redis 会：
- 只从所有 带过期时间的 key 中筛选候选集（volatile 键）；
- 随机采样 N 个 key（默认 maxmemory-samples = 5，可配置）；
- 在这些样本中，选择 counter 值最小的 key 淘汰；若 counter 相同，则进一步比较“最后访问时间”（LRU clock 字段），更久未访问的优先淘汰；
- 重复该过程，直到释放足够内存。
影响 LFU 效果的关键配置
以下参数直接影响 volatile-lfu 的行为表现：
- maxmemory-samples：采样数量越大，淘汰更接近全局最优，但耗 CPU；默认 5，建议生产环境调至 10–20 平衡精度与性能；
- lfu-log-factor：控制 counter 增长敏感度，默认 10；值越小，counter 越容易上升（对低频访问更敏感）；值越大，需要更多访问才提升（适合区分明显热/冷数据）；
- lfu-decay-time：单位为分钟，表示 counter 衰减周期，默认 1；设为 0 表示禁用衰减（counter 只增不减，慎用）。
什么时候适合用 volatile-lfu？
适用于这类场景：
- 业务中存在明确的“热点 volatile 数据”，比如带 TTL 的用户 session、临时 token、缓存结果；
- 访问模式呈现“长尾分布”：少数 key 被高频反复访问，多数 key 访问稀疏；
- 相比纯 LRU，你更希望冷门但“刚被访问过一次”的 key 不立即挤掉一个稳定中频访问的老 key。
