redis 6.0+才正式支持volatile-lfu和allkeys-lfu，低版本会静默降级为lru；需通过config get/set确认并热生效策略，商品key须按粒度命名（如prod:sku:10086）并用incr+expire维护热度，object freq返回0–255近似值仅适用于相对排序，不反映真实访问次数。
LFU在Redis里不是开箱即用的淘汰策略
Redis 6.0+ 才真正支持 volatile-lfu 和 allkeys-lfu，低版本即使配置了也会静默降级为 LRU。这不是 bug，是设计如此——LFU 需要额外的访问频次计数器和衰减逻辑，老版本压根没这结构。
实操建议：
- 先执行
redis-server --version确认 >= 6.0； - 检查当前配置：运行
CONFIG GET maxmemory-policy，确认返回值是volatile-lfu或allkeys-lfu； - 别直接改
redis.conf就完事，要用CONFIG SET maxmemory-policy allkeys-lfu热生效，并验证内存淘汰是否真的按频次触发（可配合INFO memory观察evicted_keys增长节奏）。
怎么让商品Key自带LFU“热度指纹”
LFU 不会自动识别“商品ID”，它只统计 GET/INCR 等命令对 Key 的访问次数。所以必须把商品行为映射成 Key 访问，且避免 Key 泛化（比如不能全用 product:hot 一个Key存所有）。
常见错误现象：用 INCR product:hot 统计总热度 → 所有商品挤在一个 Key，完全丢失个体区分度。
正确做法：
- Key 命名带商品粒度：如
prod:sku:10086、prod:item:20240517； - 用
INCR或INCRBY更新热度（比SET+ 解析更原子、更轻量）； - 搭配过期时间控制生命周期：比如
INCR prod:sku:10086后紧跟EXPIRE prod:sku:10086 86400，避免冷 Key 占内存又不参与 LFU 排序。
用OBJECT FREQ查实时热度时要注意精度陷阱
OBJECT FREQ 返回的是 LFU 计数器的近似值（0–255），不是真实访问次数。它经过对数压缩和周期性衰减，目的是节省内存和避免计数器溢出。这意味着：访问 1 次和访问 10 次可能都返回 1；访问 100 次和 1000 次可能都返回 10。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
使用场景：只适合做相对排序（比如 Top 100），不适合做绝对数值分析（比如“今天被查了 327 次”）。
性能影响：
-
OBJECT FREQ是 O(1) 的，但频繁调用仍会增加主线程负担； - 别在大集合上遍历查：
KEYS prod:sku:*+ 每个都OBJECT FREQ→ 可能阻塞几秒； - 推荐方案：用
SCAN分批 + Lua 脚本聚合，或导出后离线处理。
为什么LFU结果和业务感知的“爆款”常对不上
LFU 统计的是 Redis 层面的 Key 访问频次，但真实流量路径里存在大量缓存穿透、预热写入、后台定时刷量等干扰。比如商品详情页接口做了本地缓存，实际打到 Redis 的 GET prod:sku:10086 可能只有请求量的 1/5。
容易踩的坑：
- 没排除爬虫或监控探针的无效访问（它们也走正常 GET）；
- 把缓存未命中时回源 DB 再写入 Redis 的那一次
SET，误当成“热度”； - 忽略多级缓存场景：CDN / Nginx 缓存挡掉了大部分请求，Redis 根本收不到真实热度信号。
真正靠谱的做法，是把 OBJECT FREQ 结果当做一个辅助信号，和业务日志中的 UV/PV、下单转化率、加购次数对齐校验。LFU 给的是“被查得多”，不是“卖得好”。
