读写分离方案#

核心问题： 主从延迟导致读到旧数据

解决方案： 强制走主库(关键查询) / 延迟检测(判断同步进度) / 半同步复制(至少一个从库确认)

读写分离的核心思路是主库负责写、从库负责读，通过 binlog 异步复制将主库的变更同步到从库，从而分散读压力提升系统吞吐。但最大的问题是主从延迟导致读到旧数据，特别是写后立即读的场景。解决方案有三种：第一，关键业务查询强制走主库，比如用户刚修改了资料再查询时直接读主库；第二，延迟检测方案，查询前先检查从库的同步进度（seconds_behind_master 或 GTID 位点），延迟过大时自动路由到主库；第三，半同步复制，主库写完 binlog 后至少等一个从库确认收到再返回成功，牺牲一点写入延迟换取更好的数据一致性。中间件层面可以用 ShardingSphere 或 ProxySQL 来透明地做读写路由，应用层无需感知。设计时要注意不是所有读都走从库，交易、支付等强一致场景必须走主库。

追问方向：

• “主从延迟导致读旧数据怎么办？”→ 关键业务查询强制走主库、延迟检测超阈值自动切主库、写后将结果写入缓存优先走缓存、开启半同步复制减少延迟窗口
• “写后立即读怎么保证一致？”→ 最简单的方案是写后一定时间内读操作强制路由到主库；更精确的方案是基于 GTID 等待——写入后记录 GTID，读从库时等待该 GTID 回放完成再返回
• “读写分离中间件有哪些？”→ ShardingSphere-JDBC（应用层代理，轻量无额外部署）、ProxySQL/MySQL Router（独立代理层，应用无侵入）、MyCat（功能丰富但社区活跃度下降）

易错点：

• ❌ 读写分离就解决了性能——延迟问题需处理
• ❌ 所有读请求都走从库——关键查询应走主库