怎样防止主节点淘汰行为不一致|Duuu笔记
Redis进阶技巧：本文深入解析
主从节点淘汰策略必须完全一致，否则必然导致数据不一致；需统一maxmemory-policy、maxmemory值，确保read_only开启，并避免从节点写操作及运行时配置变更。
主从节点淘汰策略必须完全一致，否则数据不一致是必然的
Redis 主从复制不保证淘汰行为同步——淘汰是本地行为，从节点不会复刻主节点的
DEL
或
EVICT
操作。如果主从配置不同，比如主用
allkeys-lru
、从用
volatile-ttl
，同一时刻内存满时，两者会删掉完全不同的 key，后续读从库就可能命中脏数据或空值。
检查并统一
maxmemory-policy
配置项
这是最常见也是最致命的差异点。只要主从的
maxmemory-policy
值不一致，淘汰就不一致。
用
redis-cli -h {host} -p {port} config get maxmemory-policy
分别查主从值，确认完全相同（包括大小写）
noeviction
虽安全但容易写失败，生产环境慎用；
allkeys-*
类策略比
volatile-*
更可控，因后者依赖 TTL，而很多业务根本没设 TTL
配置文件里写死比运行时
config set
更可靠——后者重启即丢失，且主从不同步执行
config set
会导致瞬时不一致
注意
maxmemory
设置与实际可用内存的偏差
即使策略一致，若主从
maxmemory
值不同，触发淘汰的时机就不同。更隐蔽的问题是：Linux overcommit、Redis 自身内存碎片、AOF rewrite 临时内存占用，都会让“实际可分配内存” ≠
maxmemory
。
主从节点的
maxmemory
必须数值相等，建议用绝对值（如
2gb
），避免用百分比或相对单位
监控
used_memory_peak_human
和
mem_fragmentation_ratio
，如果从节点碎片率长期 > 1.5，说明它更早触发淘汰——不是策略问题，是内存管理效率差异
开启
activedefrag yes
可缓解碎片，但仅限 Redis 4.0+，且 CPU 开销明显，需权衡
从节点写操作（如
read_only no
）会彻底破坏一致性
哪怕淘汰策略和内存限制全一致，只要从节点被误设为可写（
read_only no
），它自己删 key、写 key 的行为就和主节点无关了。这种不一致无法通过复制修复。
检查
redis-cli config get slave-read-only
（旧版）或
config get replica-read-only
（6.0+），确保返回
yes
禁止在从节点执行
flushdb
、
del
、
expire
等任何修改数据的命令——这些操作不会同步到主，也不会触发主的淘汰逻辑
运维脚本或监控告警中，应把
role:slave
+
connected_slaves:0
+
slave_read_only:0
组合作为高危信号
真正难防的不是配置漏改，而是“策略一致但行为不一致”：比如主节点因客户端连接数多、请求响应快，提前触发淘汰；从节点因复制延迟积压大量待处理命令，内存涨得慢、淘汰来得晚。这种时间差导致的短暂不一致，只能靠应用层容忍或降级策略兜底。
