redis主从架构中，读写分离不分散内存淘汰压力，而是通过分流读请求降低主节点负载，延缓淘汰触发；从节点因只读且无写操作，不参与淘汰，且集群模式下readonly命令无效，仅适用于主从或哨兵模式。
单机 Redis 在高并发读场景下，内存淘汰（maxmemory 触发的 LRU/LFU 驱逐）压力会集中于主节点，不仅加剧主线程阻塞风险，还可能因频繁淘汰导致缓存命中率断崖下跌。主从架构本身不自动分担淘汰压力——淘汰只发生在写入端（即主节点），但从节点若被用于读请求，就能把大量 GET 类查询从主节点卸载出去，间接减少主节点的内存访问竞争和淘汰触发频率。关键在于：**读写分离不是靠“复制”来分摊淘汰，而是靠“分流读流量”来降低主节点的综合负载，从而延缓淘汰发生、提升整体缓存稳定性。**
为什么从节点不参与内存淘汰？
Redis 的内存淘汰策略（如 allkeys-lru、volatile-lfu）仅在写操作执行路径中触发，而从节点默认开启 slave-read-only yes，禁止写入，因此不会执行任何可能触发淘汰的命令（SET、LPUSH、EXPIRE 等）。即使你手动关闭该配置，也不应让从节点接受写请求——这会破坏主从一致性，且官方明确不支持多主。
常见错误现象：
• 误以为“从节点内存占用低，所以淘汰压力小”，其实从节点内存使用量通常与主节点几乎一致（全量同步后数据集相同）；
• 在从节点上执行 CONFIG SET maxmemory 1gb，结果无效或报错，因为从节点拒绝修改运行时内存限制类配置。
如何让读请求真正落到从节点？
必须显式启用 READONLY 并确保连接未被重定向。集群模式（redis-cli -c 或 JedisCluster）下该命令直接报错，因此读写分离只适用于纯主从或哨兵模式。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 客户端连接从节点后，**必须调用
slave.execute_command('READONLY')（Python）或connection.setReadonly(true)（Lettuce）**，否则部分客户端会默认拒绝读请求 - 检查从节点状态：
INFO replication中role:slave且master_link_status:up，同时确认slave-read-only配置为yes - 避免防火墙或网络策略拦截从节点端口（如
6380、6381），否则客户端看似连通，实际无法建立有效读连接 - 不要依赖 DNS 轮询或无状态负载均衡器直连从节点 IP —— 若某个从节点临时断连，请求将失败；建议配合哨兵动态发现（
sentinel.slaves('mymaster')）或服务注册中心
哪些读操作适合路由到从节点？
不是所有读都适合下推。需结合业务一致性容忍度判断：
-
GET、HGETALL、LRANGE、SCARD等只读命令可安全下发，前提是能接受毫秒级复制延迟（通常 - 涉及原子性或强一致性的读，例如
GET + INCR组合、WATCH/MULTI/EXEC块内读取，**必须走主节点**，否则可能读到旧值导致逻辑错误 - 带过期语义的读（如
TTL）也建议走主节点，因为从节点的过期判断可能滞后，TTL返回值可能比实际剩余时间长 - 高频小 key 查询（如用户 session）最适合分流；大 value 批量读（如
HGETALL千级字段）虽可分流，但要注意从节点带宽和内存页分配压力
主节点淘汰压力仍大的时候怎么办？
读写分离只能缓解，不能根治。当主节点因写入密集持续触发淘汰时，需叠加其他手段：
- 检查是否误用大 key：用
redis-cli --bigkeys定期扫描，拆分HASH或LIST类型的大结构体，避免单次写入引发大量内存重分配 - 调整淘汰策略：若业务允许，将
volatile-lru改为allkeys-lru，避免因未设 TTL 的 key 挤占空间；但需确认无关键永久数据被误删 - 限制单次写入体积：在客户端控制
SET的 value 大小（如 - 升级到 Redis 7.0+ 后，启用
active-defrag（activedefrag yes），让后台线程渐进式整理内存碎片，降低maxmemory触发频率
最易被忽略的一点：**从节点的 maxmemory 配置必须与主节点一致，且不能设得更小**。否则从节点可能提前开始淘汰，导致数据不一致（比如主节点还有 key A，从节点已将其驱逐），此时读请求返回空，业务误判为数据丢失。
