适用场景

读写分离能显著提升读能力，但代价是"可能读到旧数据"。哪些场景能接受延迟、哪些必须走主库，要提前定清楚。

配置步骤（读写分离实现）

# ShardingSphere 风格
spring.shardingsphere.rules.replica-query.data-sources.prds.master-data-source-name: master
spring.shardingsphere.rules.replica-query.data-sources.prds.slave-data-source-names: slave0, slave1
spring.shardingsphere.rules.replica-query.load-balancers.prds.type: ROUND_ROBIN

关键参数与建议

  • 实现方式：应用层路由、中间件（代理）、驱动层（如 ShardingSphere）
  • 强一致读：写后立即查询、支付与库存类必须走主库
  • 延迟监控：主从延迟超阈值时自动摘除从库
  • 故障切换：从库故障透明摘除，主库故障走高可用流程
  • 压测验证：读流量分摊是否生效、延迟是否可控

容易踩的坑

  • 全部读都走从库，写后查询读到旧值
  • 只配一个从库，从库故障读能力减半
  • 事务内读也走从库，数据不一致

验证与巡检

# 验证：写后立即读走主库；统计读流量主从分布
  • 巡检：主从流量比例、强一致读配置

小结

读写分离的验收：读 QPS 显著分担、延迟可控、切换演练通过、没有业务"读到旧数据"投诉。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。