redis内存爆满时，仅调maxmemory-policy无效；需联动配置maxmemory、lfu-log-factor（建议15-20）、lfu-decay-time（建议1分钟），并配合业务层设ttl或逻辑过期、入口限流及分片，才能真正防oom。
突发流量下Redis内存爆满，光调maxmemory-policy没用
单独设allkeys-lfu或volatile-lru不能防OOM。LFU不是自动熔断开关，它只决定“淘汰谁”，不控制“要不要写入”。流量突增时，如果Key没TTL、计数器参数没调、基线内存没预估，照样触发OOM command not allowed when used memory > 'maxmemory'错误。
- 短生命周期Key（如
session:abc123）若没设EXPIRE，volatile-lfu直接退化成noeviction，写入直接失败 -
lfu-log-factor默认10，在秒级万级请求下，计数器暴涨，刚热起来的爆款可能被误判为“噪声”踢出 -
allkeys-lfu比allkeys-lru多存16bit访问频次字段，实测内存开销高约15%，压测时若忽略这点，上线后碎片率可能突然冲到1.8+
真正起作用的是maxmemory + lfu-log-factor + lfu-decay-time三者联动
动态调整maxmemory必须带上下文：不是加个1GB就完事，得按真实访问模式反推。比如秒杀场景，先列必读Key类型：product:1001、sku:2005:stock、activity:seckill:config，再估算单Key平均大小（JSON约2KB，string约128B），最后留出30%余量给Lua栈、临时队列、客户端缓冲区。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
-
lfu-log-factor建议设15或20：值越大，计数器增长越慢，抗瞬时刷屏能力越强 -
lfu-decay-time建议设1（单位分钟）：衰减太慢（如30）会让已下架商品长期霸占内存；太快（如0.1）又导致刚热的Key还没稳住就被踢 - 验证是否生效：执行
CONFIG GET lfu-log-factor和CONFIG GET lfu-decay-time，必须看到你设的值，不是默认值
业务层不配合，再好的LFU也白搭
Redis不管语义，只管内存。它不会主动判断“这个配置该不该过期”“这个用户偏好还有效吗”。所有依赖“永不过期”的设计，必须由业务层埋逻辑过期字段，否则缓存就变成内存黑洞。
- ✅ 正确做法：Key设永不过期，value里塞
{"exp": 1743790260, "data": {...}}，由应用读取后判断exp - ❌ 错误做法：把
user:pref:789设成永久Key，又没在代码里检查有效期，冷数据越积越多 - 高频但短命的数据（如
seckill:queue:2005）必须用EXPIRE显式控制生命周期，不能靠LFU“等它变冷”
限流和分片不是可选项，是前置条件
缓存只是缓冲层，不是保险丝。突发流量进来前，必须在入口处卡住——靠Redis实现的令牌桶或漏桶，比单纯扩内存更可靠。
- 令牌桶适合允许突发但需平滑处理的场景（如API限流），用Hash存
tokens和timestamp，配合Lua保证原子性 - 漏桶适合严格控速场景（如下单频率限制），用List做队列，
LPUSH+LLEN+EXPIRE组合判断是否满载 - 单实例扛不住时，别硬调参，优先分片：按
user_id % 8或hash(key) % N路由，比集群更轻量、更可控
client-output-buffer-limit和repl-backlog-size——它们在突发流量下会悄悄吃掉大量内存，且不体现在INFO memory的used_memory里。上线前务必查这两项配置。
