redis主从架构不自动读写分离，需客户端或中间件显式实现；lettuce通过readfrom策略（如replica_preferred）支持从节点读路由，但写命令始终走主节点；关键业务读应直连主或结合wait/降级策略保障一致性；动态拓扑下应避免硬编码ip，推荐使用哨兵或云服务高可用域名。
Redis主从架构本身不自动做读写分离
Redis主从复制只是数据同步机制，READONLY 命令和 replica-read-only yes 配置只控制从节点是否接受写，**不会让客户端自动把 GET 发到从节点、把 SET 发到主节点**。读写分离必须由客户端或中间件显式实现。
常见错误现象：应用直连主节点，所有读请求压在主上，主节点 CPU 和网络带宽先扛不住；或者用轮询方式把读随机打到任意节点，结果读到过期/未同步的数据。
- 必须在客户端代码里区分读/写操作，并为读操作维护一组从节点连接池
- 不能依赖 Redis 自身“智能路由”，它没有这个能力
- 如果用了连接池（如 JedisPool、Lettuce），要确保读操作从从节点池取连接，写操作从主节点池取连接
Lettuce 客户端如何配置多节点路由
Lettuce 支持 MasterSlaveClient 模式，能自动识别主从关系并按需分发命令，但默认仍把所有命令发给主——需要手动开启读操作的从节点路由。
关键点是设置 ReadFrom 策略，例如：ReadFrom.REPLICA_PREFERRED 表示优先读从，主不可用时降级读主；ReadFrom.REPLICA 则强制只读从（主从断连时直接报错）。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
ReadFrom只影响读命令（GET、HGET、LRANGE等），写命令（SET、HSET）永远走主 - 节点拓扑发现依赖 Redis 的
INFO REPLICATION或哨兵（Sentinel）推送，确保你的 Lettuce 配置了正确的发现方式 - 如果用的是直连 IP 列表（非哨兵/集群），要手动在
RedisURI中标记角色，否则 Lettuce 无法识别主从
手动路由时怎么避免读到脏数据
主从异步复制导致从节点存在延迟，GET key 可能返回旧值或 nil（key 已在主上删除但未同步）。这不是客户端 bug，是架构固有约束。
业务上要接受最终一致性，但某些场景（如登录态校验、订单状态查询）需要强一点的保证。这时候不能只靠“随机选一个从”，得加一层判断。
- 用
REPLICAOF NO ONE临时提升从为主来验证数据，代价高，仅限紧急修复 - 更实际的做法：对关键 key，先查主（加
READWRITEhint 或直连主连接），再降级查从；或用WAIT 1 1000命令等至少 1 个从确认收到（注意这会阻塞主） - 监控
lag指标（INFO REPLICATION中的master_repl_offset和从节点的slave_repl_offset差值），自动剔除 lag > 100MB 或 > 5s 的从节点
为什么别在应用层硬编码从节点地址
把从节点 IP 写死在配置里，看着简单，但一旦发生故障切换、扩容缩容或网络调整，就得改代码、发版、重启——完全违背 Redis 主从设计初衷。
真实环境里，主从关系是动态的。哨兵模式下主可能漂移；集群模式下 slot 分布变化；甚至云数据库（如阿里云 ApsaraDB、腾讯云 CRS）后台会自动运维节点。
- 用哨兵（Sentinel）时，客户端应连接哨兵地址，由哨兵返回当前主/从地址，而不是自己解析
sentinel get-master-addr-by-name结果 - 用云服务时，务必使用其提供的高可用域名（如
xxx.redis.rds.aliyuncs.com），背后 DNS 已做健康探测和自动切换 - 如果非要直连，至少封装一个轻量服务定期调用
INFO REPLICATION并缓存拓扑，避免每次请求都去探测
