redis只读副本不触发淘汰策略，因其maxmemory和maxmemory-policy配置完全被忽略；内存增长依赖主节点同步流，爆满时会触发oom killer而非redis自身淘汰。
Redis只读副本（replica）在内存耗尽时，根本不会触发任何淘汰行为——它连 maxmemory 限制和 maxmemory-policy 都不生效。
只读副本不执行内存淘汰策略
Redis 副本节点默认是只读的（replica-read-only yes），但它不是“缓存节点”，而是主从同步的副本来提供读扩展或容灾。关键点在于：
– 它的 maxmemory 配置即使设了，也**完全被忽略**；
– CONFIG GET maxmemory-policy 返回的值只是配置项快照，不代表实际运行逻辑；
– 所有淘汰策略（如 allkeys-lru、volatile-ttl 等）仅在**主节点（master）写入路径中触发**，副本不走写入内存分配流程。
为什么副本不淘汰？——它根本不“申请新内存”来写数据
副本的数据更新全部来自主节点的复制流（repl stream），包括 RDB 加载和 AOF/PSYNC 同步。整个过程是：解析命令 → 直接写入底层数据结构 → 不经过常规的写命令校验链路。
因此：
– 内存增长由主节点写入节奏决定，副本自身无权决定“删谁”；
– 即使副本 used_memory 达到物理上限，也不会拒绝同步，而是可能触发 OOM killer 杀死进程（操作系统层面）；
– INFO memory 中的 used_memory 和 used_memory_rss 仍会增长，但不会触发 Redis 自身的淘汰逻辑。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
真实风险：副本内存爆满后不是“淘汰”，而是崩溃或同步中断
当副本所在机器内存不足时，常见现象不是 key 消失，而是：
– 进程被 Linux OOM killer 终止（dmesg | tail 可见日志）；
– redis-cli -p 6380 INFO replication 显示 master_link_status:down；
– 日志出现 Can't handle RDB format version 或 Failed to allocate memory for bulk read；
– 如果启用了 replica-ignore-maxmemory yes（Redis 7.0+），副本会跳过对 maxmemory 的检查，但该配置**不启用淘汰，只避免启动失败**。
生产环境必须注意的盲区
很多人给副本配了 maxmemory 4gb 和 allkeys-lru，以为能“自动保命”。实际上：
– 这些配置在副本上纯属无效字段，Redis 启动时甚至不校验它们是否合理；
– 副本内存管理完全依赖 OS 和主节点写入压力，你无法靠策略“兜底”；
– 真正有效的做法只有两个：给副本预留足够内存余量（建议 ≥ 主节点峰值的 1.3 倍），或用 memtier_benchmark + redis-cli --stat 持续监控 used_memory_peak_human。
