主从节点maxmemory值不一致会导致从库数据被提前淘汰、主从数据丢失；需统一阈值、启用replica-ignore-maxmemory yes禁用从库本地淘汰、并通过配置中心固化配置防止漂移。
主从节点 maxmemory 值不一致，是导致从库数据被提前淘汰、主从数据丢失最隐蔽也最危险的配置问题之一。它不会报错，复制能照常进行，但一旦内存压力上升，从库就会按自己的小内存阈值主动删数据——而主库还完好存着，后续故障切换时直接“丢数据”。解决核心就三点：统一阈值、禁用从库本地淘汰、加固配置落地机制。
统一主从 maxmemory 数值与单位
不能只看“都是4G”这种表面一致。必须确认：
- 配置文件中 maxmemory 的数值完全相同（例如都写
maxmemory 4294967296字节，或都写maxmemory 4gb），避免因单位解析差异（如4gvs4gb）导致实际值偏差 - 主从节点均通过
CONFIG GET maxmemory实时验证，而非仅依赖配置文件注释或部署脚本中的变量 - 注意 Linux overcommit 行为和 Redis 内存碎片影响：即使设了
4gb，从节点若运行在内存紧张的宿主机上，used_memory_rss可能远超该值，触发系统 OOM killer —— 此时不是 Redis 淘汰，而是进程被杀
强制从库忽略自身 maxmemory 限制
Redis 6.0+ 提供了关键配置项 replica-ignore-maxmemory yes，让从节点彻底放弃本地内存淘汰逻辑，完全依赖主节点同步来的 DEL 或过期指令回收内存：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须在从节点配置文件中显式设置，并重启生效；运行时
CONFIG SET不可靠，且重启即丢失 - 启用后，从节点
INFO memory中的evicted_keys应长期为 0，mem_allocator相关指标不再受maxmemory约束 - 副作用需预判：从节点内存会随主库增长而持续上涨，务必确保其所在机器有足够物理内存余量，建议预留 ≥30% 缓冲空间
阻断运行时配置漂移与重启失效风险
很多线上事故源于“人肉 config set”或配置未固化：
- 禁止在生产环境对主从任意节点执行
CONFIG SET maxmemory或CONFIG SET maxmemory-policy—— 这类变更不复制、不同步、不持久 - 所有配置必须写死在
redis.conf中，并纳入配置中心或 IaC（基础设施即代码）管理，每次发布自动校验主从配置 diff - 哨兵或 Cluster 模式下，故障切换后新主节点可能沿用旧从节点配置（如
replica-ignore-maxmemory yes在升主后失效），需在切换后自动触发配置重载检查
不复杂但容易忽略：真正起效的不是“设了多大内存”，而是“谁来决定删什么、什么时候删”。把淘汰权收归主节点，再锁死配置源头，就能切断从库擅自剔除数据的路径。
