网络分区后客户端向失联从节点发请求会直接失败；需通过INFO replication检查master_link_status和复制延迟来主动剔除异常节点，而非仅依赖TCP连通性。
主从节点网络分区后，客户端仍发请求到失联从节点会怎样
直接失败。Redis 从节点在无法连接主节点时，INFO replication 中的 master_link_status:down 会持续为 down，但多数客户端（如 redis-py）不会自动感知这个状态；若你手动配置了读连接池指向该从节点，后续 GET 请求将抛出 ConnectionError 或超时异常，而不是降级或跳过。
- 不是所有从节点都“不可用”——可能只是某台从节点与主节点断连，但与其他客户端网络正常
- 客户端若未做健康检查，会继续把读流量打过去，造成大量超时，而非静默切换
- Lettuce 的
ReadFrom.SLAVE_PREFERRED默认不校验master_link_status，只看 TCP 连通性，这点容易被忽略
如何让客户端主动识别并剔除失联的从节点
必须在初始化或定期探测阶段，用 INFO replication 检查每个从节点的同步状态，不能只依赖 ping 或 connect。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 对每个从节点执行
redis-cli -h <ip> -p <port> INFO replication</port></ip>，解析返回中的master_link_status:up和slave_repl_offset - 对比主节点的
master_repl_offset（需单独查主节点），差值超过阈值（如 > 10MB）即视为复制延迟过大，应临时下线该从节点 - 使用 Lettuce 时，可配合
ClusterTopologyRefreshOptions开启拓扑刷新，并自定义NodeSelectionStrategy过滤掉master_link_status:down的节点 - redis-py 没有内置机制，需自己封装
StrictRedis实例 + 健康检查定时任务 + 连接池热替换逻辑
网络分区期间写请求是否还能成功
只要客户端能连上主节点，写请求不受影响；但要注意：主节点在检测到多数从节点失联后，可能触发 min-slaves-to-write 和 min-slaves-max-lag 配置限制，主动拒绝写入。
- 检查主节点配置：
min-slaves-to-write 2表示至少要有 2 个从节点在线才允许写 -
min-slaves-max-lag 10表示从节点最大允许落后 10 秒，超时即视为不可用 - 此时客户端收到的错误是
NOREPLICAS Not enough good replicas to write，不是网络错误，需捕获并告警，而非重试 - 该行为是主节点单方面决定的，客户端无法绕过，也不能靠重连解决
路由策略必须区分“连接可达”和“角色可用”
这是最容易踩坑的地方：TCP 能通 ≠ 从节点能服务读请求 ≠ 主节点能接受写请求。网络分区后，节点可能处于“半活”状态——监听端口开着，但复制链路已断、数据陈旧、甚至被降级为孤立节点。
- 不要用
socket.connect()或PING判断节点是否可用，必须走INFO replication或CLUSTER NODES（集群模式）获取真实角色与同步状态 - 在配置双连接池（
master_pool/slave_pool）时，slave_pool的节点列表必须动态更新，不能写死 - 若用哨兵（Sentinel），
sentinel.get_master_address_by_name()只返回当前主节点地址，不提供从节点健康信息，仍需额外探测
INFO replication 的解析结果和业务请求成功率、延迟指标联动起来，否则再好的负载均衡也压不住一个假活的从节点。 
