主从节点maxmemory-policy必须完全一致，否则淘汰行为分裂导致脏读或空值；需通过config get校验大小写一致，禁止运行时set，须配置文件硬编码并diff校验。
主从节点maxmemory-policy必须完全一致
只要主从配置中 maxmemory-policy 值不同，淘汰行为就必然分裂——比如主库用 allkeys-lru，从库用 volatile-ttl，同一内存压力下删的 key 完全不同，从库读出来就是脏数据或空值。
实操建议：
- 用
redis-cli -h {host} -p {port} config get maxmemory-policy分别查主从，确认返回值（含大小写）一字不差 - 禁止运行时
config set maxmemory-policy：重启即失效，且主从无法同步执行，极易造成瞬时不一致 - 配置文件里硬编码该值，上线前做
diff校验
WAIT 不能解决淘汰导致的脏读
WAIT 1 1000 只保证写命令（如 DEL）已传播到至少一个从节点的复制缓冲区，并不保证它已被执行。如果从节点正卡在 BGSAVE、慢查询或 AOF rewrite，命令会在缓冲区排队，直到它腾出 CPU 才真正执行淘汰。
这意味着：你刚 DEL order:123 并 WAIT 成功，紧接着读从库，仍可能命中旧值——因为 DEL 还没落地。
所以对强一致性 key（如库存、订单状态），不要依赖 WAIT + 从库读，而应直连主节点，或改用业务层主动控制生命周期（如写 DB 后发消息清缓存）。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
maxmemory 相同也不代表淘汰时机一致
即使主从都设了 maxmemory 2gb 且策略一致，实际触发淘汰的内存水位仍可能错开。原因包括：
- Linux
vm.overcommit_memory设置影响 Redis 实际可分配内存 - Redis 内存碎片率（
mem_fragmentation_ratio）高时，used_memory显示 1.8GB，但allocator_allocated可能已达 2.5GB，触发淘汰早于预期
监控时不能只看 used_memory，要同时关注 mem_fragmentation_ratio 和 allocator_allocated，否则会误判内存余量。
noeviction 看似安全，但会直接暴露业务容忍度
noeviction 虽能避免误删，但写失败会直接抛 (error) OOM command not allowed when used memory > 'maxmemory'。这不是静默降级，而是服务端明确拒绝。
生产环境需评估业务是否能接受这种中断：
- 用户注册接口写入失败？能否转异步或兜底队列？
- 计数类操作（如点赞、浏览）是否允许丢弃？
- 是否已配置告警，能在
used_memory达到 90% 时提前干预？
真正容易被忽略的是：淘汰策略不是“选完就完事”，它和 Linux 内核参数、Redis 内存分配器行为、甚至主从同步阶段的命令执行顺序深度耦合。线上排查时，先确认策略一致性，再查 info memory 中的碎片和分配器指标，比盲目调大 maxmemory 更有效。
