读写分离是什么
主库负责写、从库负责读的经典架构：从库默认只读，读请求分散到多个副本上以扩展读能力。代价是从库数据总比主库旧一点（复制延迟），所以「写后立刻读」这类场景必须回主库，否则会读到旧值。
基本信息
| 角色判定 | INFO replication 的 role 字段，master 或 slave |
|---|---|
| 从库只读 | replica-read-only 默认 yes，写入报 READONLY 错误 |
| 延迟来源 | 网络往返、主库写入速率、从库执行阻塞命令 |
| 强一致方案 | WAIT 命令等待副本确认，或读请求强制走主库 |
典型使用场景
- 读多写少业务：商品详情、榜单、配置类读取分散到多个从库
- 报表与统计查询：把扫描类请求引导到从库，避免影响主库写入
- 备份与慢命令执行：在从库上跑扫描与备份，主库只承担在线流量
- 异地就近读取：把从库部署在离用户更近的机房降低延迟
- 不适用场景：下单后立刻查订单等会话一致性要求高的读取必须回主库
客户端侧约定
客户端侧约定
# 写连接指向主库地址，读连接指向从库地址
redis-cli -h 10.0.0.10 INFO replication | grep role # master
redis-cli -h 10.0.0.11 INFO replication | grep role # slave
# 从库写入会直接报错：
# READONLY You can't write against a read only replica.
# 写入后需要强一致读：
redis-cli -h 10.0.0.10 SET order:88 paid
redis-cli -h 10.0.0.10 WAIT 1 100 # 等 1 个副本确认，最多 100 毫秒读流量路由建议
| 场景 | 路由 | 原因 |
|---|---|---|
| 普通查询与列表页 | 从库 | 允许秒级延迟，能摊薄主库压力 |
| 写后立即读 | 主库 | 避免读到旧值被误判为写入失败 |
| 事务性读取 | 主库 | 需要与刚提交的写入保持同一视图 |
| 离线统计与备份 | 从库 | 长耗时操作不影响在线写入 |
会话一致性的常见做法：同一用户的读请求固定路由到同一节点，或在写入后的短时间窗口内强制走主库。
从库只读只是默认行为，配置被改动后仍可能被写入，从而与主库数据分叉并触发复制中断。