主从节点的maxmemory-policy必须完全一致，否则淘汰行为必然分裂，导致从库读取脏数据或空值；需用redis-cli分别核查配置值（含大小写），禁止运行时config 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 校验
-
noeviction虽能避免误删，但写失败会直接抛(error) OOM command not allowed when used memory > 'maxmemory'，生产环境需评估业务容忍度
为什么 WAIT 不能解决淘汰导致的脏读
WAIT 1 1000 只保证写命令（如 DEL）已传播到至少一个从节点的复制缓冲区，并不保证它已被执行。如果从节点正卡在 BGSAVE、慢查询或 AOF rewrite，命令会在缓冲区排队，直到它腾出 CPU 才真正执行淘汰。
这意味着：你刚 DEL order:123 并 WAIT 成功，紧接着读从库，仍可能命中旧值——因为 DEL 还没落地。
所以对强一致性 key（如库存、订单状态），不要依赖 WAIT + 从库读，而应直连主节点，或改用业务层主动控制生命周期（如写 DB 后发消息清缓存）。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
从库同步延迟监控不能只看 repl_offset
仅靠 info replication 中的 master_repl_offset 和 slave_repl_offset 差值判断延迟，会漏掉关键风险点：
- 从节点可能已追上偏移量，但正在执行阻塞操作（如
KEYS *、大 value 序列化），此时repl_offset不动，但实际命令未执行 - 网络抖动导致复制缓冲区堆积，
repl_backlog_size不足时触发全量重同步，期间从库处于不可读状态 - 主节点
repl-backlog-time-limit设置过短，小延迟也会丢掉增量，被迫重同步
建议加一层轻量探测：定期向主库写一个带时间戳的 key（如 sync_probe:ts），再立刻从从库读取并比对时间差，超阈值则告警或切流。
maxmemory 值相同也不代表淘汰时机一致
即使主从都设了 maxmemory 2gb 且策略一致，实际触发淘汰的内存水位仍可能错开。原因包括：
- Linux
vm.overcommit_memory设置影响 Redis 实际可分配内存 - Redis 内存碎片率（
mem_fragmentation_ratio）高时，used_memory显示 1.8GB，但allocator_allocated可能已达 2.5GB，触发淘汰早于预期 - AOF rewrite 或 RDB save 过程中临时内存飙升，可能提前触发主库淘汰，而从库无此压力
因此，监控不能只盯 used_memory，要同时采集 mem_fragmentation_ratio、mem_allocator、aof_rewrite_in_progress 等指标，组合判断真实内存压力。
