省内存的关键在于写入侧优化而非淘汰策略——应精简key名、用Protobuf序列化用户向量、分离冷热数据，并调高maxmemory-samples至10或20以提升LFU准确性。
推荐系统里用 Redis 做缓存，想省内存，核心不是“选哪个淘汰策略”，而是“别让 Redis 存不该存的东西”——allkeys-lfu 是最贴近推荐场景的策略，但前提是数据本身得干净、结构得紧凑。
为什么 allkeys-lfu 比 allkeys-lru 更适合推荐缓存
推荐系统里的热点行为（比如热门商品点击、爆款视频曝光）天然具有强频次特征：一个 item 被反复召回、打分、排序，它的 key 会被高频访问；而冷门 item 可能写入后几小时都不被触达。LFU 淘汰的是“长期低频访问”的 key，比 LRU 更匹配这种分布。
但要注意：allkeys-lfu 的 LFU 计数器有衰减机制（默认每分钟右移一次），否则老热点会永远压着新热点上不来。如果你的业务有明显周期性（比如每日凌晨重刷推荐池），这个衰减反而是优势。
常见错误现象：
- 用了
volatile-lru却给所有缓存 key 都设了 TTL，结果刚热起来的用户画像就被提前淘汰了 - 误以为
allkeys-random“省 CPU”，实际导致缓存命中率断崖下跌，下游 DB 压力反而更大，间接推高整体资源开销
maxmemory-samples 必须调高，否则 LFU 失效
Redis 的 LFU 实现是近似算法：每次淘汰前随机抽样一批 key，再从中挑计数最小的。默认 maxmemory-samples 是 5，对推荐系统太粗糙——容易把刚被批量写入（如实时特征更新）但尚未被读取的 key 当成“低频”干掉。
实操建议：
- 线上实例内存 ≥ 4GB 时，把
maxmemory-samples设为10或20； - 如果用的是 Redis 6.2+，可以配合
lfu-log-factor调整计数器增长斜率（默认 10，值越小，新 key 越容易追上老 key）； - 避免和
active-defrag同时高强度运行，两者都会争抢 CPU 时间片，反而拖慢响应。
真正最省内存的操作，根本不在淘汰策略里
淘汰策略只是“兜底”，省内存的关键动作在写入侧：
- 不用
HASH存用户向量，改用STRING+ Protocol Buffers 序列化，减少对象头和字段名重复开销； - 把长 TTL（如 7d）的冷数据拆到另一个 Redis 实例，主实例只留
1h~24h热数据，用volatile-lfu管理，避免 LFU 计数器被长期沉睡 key 拉低灵敏度； - 禁用
lazyfree-lazy-eviction（默认 false），防止淘汰时阻塞主线程导致请求堆积，间接引发更多 key 写入失败或重试，进一步挤占内存。
最后提醒一点：INFO memory 里的 used_memory_overhead 经常被忽略，它包含 key 名字符串、dict entry 结构、连接缓冲区等——如果你的推荐 key 是 rec:user:123456:session:789 这种长格式，光 key 名就占几十字节，批量写入时 overhead 可能占到总内存 30% 以上。缩短 key 名、复用前缀、用整数 ID 替代字符串 ID，比调任何淘汰参数都管用。
