选对maxmemory-policy能显著缓解写阻塞但不提升读性能；它解决内存满后写不进去的问题，而非读得慢。当内存达限时，noeviction策略使写命令直接报oom错误，而allkeys-lru等淘汰策略可主动腾空间保障写可用性；选择需结合ttl使用情况，配合maxmemory-samples调优，并依赖系统参数协同生效。
选对 maxmemory-policy 能显著缓解写阻塞，但不会直接提升读性能；它解决的是“内存满后写不进去”的问题，而不是“读得慢”。
为什么 maxmemory-policy 会影响写操作成功率
当 Redis 内存达到 maxmemory 限制时，若策略是 noeviction（默认），所有写命令（如 SET、HSET）会直接返回错误：(error) OOM command not allowed when used memory > 'maxmemory'。业务写入瞬间失败，表现为接口超时或报错。
而启用淘汰策略（如 allkeys-lru）后，Redis 会在写入前主动腾出空间，写命令可继续成功执行——这是“写可用性”的底线保障。
-
noeviction：最安全但最脆弱，适合只读或有强保活机制的场景 -
volatile-*类策略：仅淘汰带EXPIRE的 key，要求你必须给所有缓存设 TTL -
allkeys-*类策略：无条件淘汰，适合纯缓存、无敏感数据的场景
allkeys-lru 和 volatile-lru 怎么选
关键看你的 key 是否普遍设置了过期时间。
- 如果大部分缓存都用了
SET key val EX 3600这类带 TTL 的写法 → 用volatile-lru更精准，避免误删永久配置类 key - 如果大量 key 没设 TTL（比如用
SET key val直接写入，靠业务逻辑清理）→ 必须用allkeys-lru，否则内存永远涨不下去 -
volatile-ttl在秒杀类场景有用：优先淘汰马上要过期的 key，减少无效驱逐开销
注意：volatile-lfu 和 allkeys-lfu 需 Redis ≥ 4.0，且实际命中率提升有限，除非你有明确热点识别需求，否则 LRU 更稳定。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
配合 maxmemory-samples 调整淘汰精度
maxmemory-policy 的效果高度依赖采样数：maxmemory-samples 默认是 5，即每次淘汰只随机检查 5 个 key 来估算 LRU/LFU 状态。
- 值太小（如 3）→ 淘汰随机性大，可能频繁踢掉刚写入的热 key
- 值太大（如 20）→ 每次淘汰耗 CPU 更多，高并发下影响吞吐
- 生产建议值：10～15，平衡精度与开销；可通过
INFO stats查看evicted_keys和expired_keys增长是否平滑
修改方式（运行时生效）：CONFIG SET maxmemory-samples 12
容易被忽略的底层依赖
maxmemory-policy 不是孤立参数，它依赖系统和 Redis 自身配置才能正常工作：
- Linux 必须设置
vm.overcommit_memory = 1，否则 fork 子进程（如 RDB）可能失败，间接导致淘汰卡顿 -
tcp-backlog和net.core.somaxconn要匹配，否则连接堆积会掩盖内存压力的真实表现 - 如果启用了 AOF +
appendfsync everysec，淘汰触发时的写放大可能加剧磁盘 I/O 延迟
真正决定读写性能上限的，从来不是单个淘汰策略，而是内存水位是否稳定、淘汰是否及时、以及有没有大 key 占着内存不放——maxmemory-policy 只是最后一道闸门，不是加速器。
