必须一致。主从或集群各节点的maxmemory-policy值只要不完全相同，就必然导致淘汰行为分裂，引发脏读、空值或数据丢失；需逐节点用redis-cli config get验证大小写精确一致，并在redis.conf硬编码配置。
必须一致。主从节点或集群各分片节点的 maxmemory-policy 值只要不完全相同，就一定会导致淘汰行为不一致，进而引发数据不一致——这不是概率问题，是确定性结果。
为什么主从/集群节点淘汰策略必须完全一致
Redis 的淘汰是本地行为：主节点删掉某个 key，不会同步 DEL 命令给从节点；从节点内存满时，自己按自己的 maxmemory-policy 决定删谁。如果主用 volatile-lru、从用 allkeys-lru，同一时刻触发淘汰，两者删的 key 极大概率完全不同。后续读从库可能命中脏数据（旧值）、空值（该有的 key 被误删），或根本读不到应存在的 key。
- 淘汰不走复制流，不参与 AOF/RDB，纯内存本地决策
-
config set maxmemory-policy是运行时命令，重启即失效，且主从各自执行后极易产生瞬时不一致 - 大小写敏感：
allkeys-lru和AllKeys-LRU在 Redis 看来是两个不同策略
如何检查并统一各节点的淘汰策略
逐个连接节点，用 config get maxmemory-policy 查值，不能只信配置文件或脚本输出——运行时可能被改过。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 命令示例：
redis-cli -h 192.168.0.213 -p 6692 -a 'Tiye@54L2!' config get maxmemory-policy - 集群环境下，需对每个 master 和 slave 节点都执行，不能只查 master
- 确认返回值完全一致，比如都是
volatile-lru，而非volatile-lruvsvolatile-lfu - 若发现不一致，优先修改 redis.conf 并重启节点，而非用
config set临时修复
maxmemory 值也要一致，但容易被忽略
即使策略相同，maxmemory 值不同也会导致淘汰时机错位：主节点在 3.8G 触发淘汰，从节点在 4.0G 才触发，中间窗口期主已删 key、从还没删，复制延迟 + 淘汰不同步 = 数据视图分裂。
- 检查命令：
config get maxmemory，注意单位（bytes / mb / gb）是否统一 - 集群中每个 shard 的 master 节点
maxmemory应相同，slave 节点也应与对应 master 相同 - Linux overcommit、AOF rewrite 临时内存占用会让“实际可用内存” ≠
maxmemory，所以maxmemory设为总内存的 70%~75% 更稳妥
真正麻烦的不是配错一次，而是配错后难以复现——它只在内存压测、流量突增、key 大量过期等临界点暴露，且表现随机。最保险的做法：所有节点的 maxmemory 和 maxmemory-policy 都写死在 redis.conf 里，上线前 diff 配置文件，而不是靠运维脚本临时 set。
