redis主从读写分离需客户端显式控制，服务端仅同步数据；可通过api探测节点角色、配置双连接池或使用lettuce的readfrom.slave_preferred实现路由，同时须校验从节点只读模式、健康状态与复制延迟。
Redis主从读写分离必须由客户端自己控制
Redis服务端本身不提供读写分离的路由能力，SLAVEOF 或 REPLICAOF 只负责数据同步，所有客户端发往从节点的读请求、发往主节点的写请求，都得靠客户端代码显式区分。依赖中间件（如Redis Proxy）是另一条路，但“客户端配置负载均衡路由策略”这个需求，本质就是要求你在应用层做节点选择和流量分发。
如何在代码里区分主节点和从节点并路由
多数 Redis 客户端库（如 Jedis、Lettuce、StackExchange.Redis、redis-py）支持传入多个节点地址，但默认行为通常是「全部连主」或「随机选一个」，不会自动识别角色。你需要主动调用 API 获取节点角色，或提前在配置中声明角色。
-
redis-cli -h 10.0.1.2 -p 6379 INFO replication返回的role:master或role:slave是最准的判断依据，但不能每次请求都去查——适合初始化时探测 - Lettuce 支持
MasterSlave.connect(…)+ReadFrom.SLAVE_PREFERRED，它会自动把读请求发给从节点（若从节点可用），写请求强制走主节点 - redis-py 没有内置读写分离逻辑，需手动维护两个连接池：
redis.Redis(connection_pool=master_pool)用于写，redis.Redis(connection_pool=slave_pool)用于读 - 注意：从节点可能因网络延迟或复制中断而滞后，
INFO replication中的slave_repl_offset和主节点的master_repl_offset差值过大时，应临时剔除该从节点
负载均衡不是简单轮询从节点，得考虑健康与延迟
把读请求平均分给所有从节点，看似均衡，实则容易把流量压向响应慢或已断连的节点。真实场景下，必须叠加健康检查和动态权重。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 定期执行
PING或INFO server探活，失败超过阈值（如连续3次）则标记为不可用，并从从节点列表中临时移除 - 记录每个从节点的
latency（可用redis-cli --latency -h x.x.x.x -p yyyy评估），按响应时间倒排权重，快的多分流量 - 避免“热key打爆单个从节点”：对高频读 key（如商品详情），可加一层本地缓存或使用一致性哈希将同类 key 固定到某从节点，减轻单点压力
- 写操作后立即读（read-after-write）必须走主节点，否则可能读到过期数据；业务上需显式标注这类读为
read_from_master=true
常见错误：从节点只读模式没开或被意外写入
即使你把读请求发给了从节点，如果它没启用只读模式，仍可能接受写命令（比如误发 SET），导致复制冲突甚至从节点宕机。
- 确认从节点配置中启用了
replica-read-only yes（旧版叫slave-read-only yes），这是默认值，但某些运维脚本可能覆盖它 - 连接从节点后执行
CONFIG GET replica-read-only，返回["replica-read-only","yes"]才安全 - 若发现从节点响应了写命令（如返回
(error) READONLY You can't write against a read only replica.以外的错误），说明它已被人为设为可写，或版本太低（ - 客户端日志里出现大量
READONLY错误，往往不是代码问题，而是你误把写请求发到了从节点连接池
真正难的不是配几个 IP 或写个轮询函数，而是让路由策略感知节点状态变化、容忍复制延迟、适配业务一致性要求。很多线上事故，都出在“以为从节点可用”和“实际刚断连5秒”之间的那几毫秒里。
