Redis从库默认不触发内存淘汰，因其设计为只读副本，淘汰逻辑被源码硬性禁用（server.masterhost非空时freeMemoryIfNeeded直接返回）；配置maxmemory-policy无效，仅主库淘汰有效。
从库（slave）默认不启用内存淘汰策略
Redis 从库即使配置了 maxmemory 和 maxmemory-policy，也不会主动触发内存淘汰。这不是 bug，而是设计使然：从库的定位是只读副本，所有写操作均由主库驱动，其数据生命周期完全受主库控制。淘汰逻辑仅在「主动写入导致内存增长」的场景下有意义，而从库的写入（如 RDB 加载、AOF 重放、PSYNC 同步）被视为“重建状态”，不是用户请求驱动的写行为。
常见错误现象包括：
- 从库
INFO memory显示used_memory_human超过maxmemory，但evicted_keys始终为 0 - 主库已设
allkeys-lru，从库CONFIG GET maxmemory-policy返回相同值，却无任何淘汰发生 - 监控发现从库内存持续上涨，甚至 OOM 被系统 kill，但日志里没有
OOM command not allowed报错（因为从库不拒绝命令）
从库内存超限的真实风险不在淘汰，而在同步与稳定性
从库不淘汰 ≠ 安全。它意味着：
- 主库推送的大量 key（尤其是未设 TTL 的配置类、白名单类 key）会原样堆积在从库内存中，无法被策略清理
- RDB 加载阶段可能瞬间突破
maxmemory，但 Redis 不会在加载时做淘汰判断——它先全量载入，再开始接受客户端请求 - 若从库同时开启
replica-serve-stale-data yes（默认），它仍可提供过期/不一致的数据，但内存压力已不可控
性能影响明显：内存持续高位会加剧 swap 使用、GC 压力，最终表现为 sync_full 耗时增加、repl_backlog 溢出、从库频繁断连重同步。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
想让从库“参与”内存管理？只有两个务实路径
不要试图让从库执行淘汰策略——它不支持。可行做法是：
- 主库严格管控写入特征：所有缓存类 key 必须带 TTL（用
SETEX/EXPIRE），避免长生命周期 key 污染从库；对必须长期存在的 key（如权限表），单独建库或用SELECT隔离 - 从库配置
maxmemory仅作监控阈值，配合redis_exporter+ Prometheus 告警：redis_memory_used_bytes / redis_memory_max_bytes > 0.9，而非依赖其自动干预 - 若业务允许，将从库设为
replica-read-only yes（默认）且禁用所有写命令（通过rename-command屏蔽SET等），彻底杜绝非同步写入带来的内存不可控
为什么 CONFIG SET 在从库上能成功却无效
执行 CONFIG SET maxmemory-policy allkeys-lru 在从库上不会报错，是因为该命令本身只是修改配置项。但 Redis 源码中，淘汰逻辑的入口函数 freeMemoryIfNeeded() 有硬性检查：
if (server.masterhost || server.loading) return 0;
即：只要处于从库模式（server.masterhost 非空）或正在加载数据（server.loading 为真），直接跳过淘汰流程。所以配置值变了，行为没变——这是最容易被忽略的底层事实。
