LFU策略本身不能解决热点Key性能瓶颈，仅负责识别和保留热点Key；缓解瓶颈需配合客户端本地缓存或多副本路由。redis-cli --hotkeys返回空因LFU计数器未启用，须同时满足：maxmemory-policy设为volatile-lfu或allkeys-lfu、lfu-log-factor与lfu-decay-time未被注释或设为0；OBJECT FREQ返回值忽高忽低是因LFU采用概率对数计数器（8位，最大255），非精确计数，适合相对热度比较而非绝对访问量；写操作变慢仅在写密集+高key复用场景明显（实测延迟高0.2~0.4ms），读多写少场景无额外开销；LFU不改变哈希分片逻辑，热点Key仍集中于单节点，必须通过本地缓存或多副本路由分流访问路径。
LFU策略本身不能解决热点Key的性能瓶颈，它只负责“识别”和“保留”热点Key；真正缓解瓶颈，必须配合客户端本地缓存或多副本路由。
为什么redis-cli --hotkeys返回空结果？
这是最常踩的坑：命令依赖LFU计数器，但计数器不会自动启用。你得确认三件事：
-
maxmemory-policy已设为volatile-lfu或allkeys-lfu -
lfu-log-factor未被注释（默认10，可接受） -
lfu-decay-time未被注释（默认1，单位分钟）
只要其中任意一项被注释或设为0，Redis就退化为近似LRU行为，--hotkeys必然无输出。别只改policy，漏掉后两项等于白配。
LFU的OBJECT FREQ返回值为什么忽高忽低？
因为LFU用的是概率对数计数器，不是精确计数：
- 低频访问时，
counter增长概率高；高频后，概率指数级下降 - 8位
counter最大255，实际能表示的访问次数远超此值（比如lfu-log-factor 10下，counter=100 ≈ 实际访问约1万次） - 单次
OBJECT FREQ key只反映当前近似热度，不能跨key比大小，更不能当绝对访问量用
想看真实热度排序，直接跑redis-cli --hotkeys——它内部采样+聚合，比手动查单个key靠谱得多。
写操作变慢是不是LFU导致的？
是，但只在特定场景下明显：
- 读多写少（如商品详情页缓存）：LFU无额外开销，
GET仍为O(1) - 写密集+高key复用率（如session更新、实时计数器）：每次
SET已存在key都要原子更新8位counter，实测QPS 5万+时比LRU延迟高0.2~0.4ms - 若业务对写延迟敏感（如风控规则写入），建议压测对比；临时切回
volatile-lru可验证是否为LFU引入
注意：LFU的衰减机制（lfu-decay-time）只在后台定时任务触发，不影响单次写操作路径。
LFU启用后，热点Key还是打爆单节点？
因为LFU不改变Redis集群的哈希分片逻辑——hot_key永远落在固定slot，所有请求仍打到同一物理节点。必须从访问路径分流：
- 本地缓存（Caffeine/Guava）：进程内存存value，绕过网络IO和Redis单线程，但需设短TTL（如2秒）、限容量、写时主动清理
- 多副本路由：客户端随机读
hot_key:replica0/hot_key:replica1等，写时pipeline全量更新；副本必须带TTL，且由写操作刷新，否则主key过期后副本变脏
这两招才是治本之策；LFU只是帮你把真正的hot_key筛出来，不筛准，后面所有优化都无从谈起。
