SQL读写分离如何实现_业务接入架构设计说明【教学】

SQL读写分离需通过中间层或应用层路由控制实现写主读从，保障一致性、自动切换与业务无感；核心在于路由策略设计、业务接入改造及上线前影子流量、宕机演练和慢SQL检查。

SQL读写分离不是简单配两个数据库地址就能生效，核心在于让写操作只走主库、读操作尽量走从库，同时保障数据一致性、故障自动切换和业务无感。关键不在数据库本身，而在中间层或应用层的路由控制。

一、常见实现方式对比（选型依据）

目前主流有三类方案，适用不同阶段和团队能力：

• 代理层方案（如MyCat、ShardingSphere-Proxy、MaxScale）：数据库前面加一层代理，SQL进来后由代理解析并路由。优点是业务零改造，缺点是多一跳网络、代理自身成单点（需集群部署）、复杂SQL可能解析失败。
• JDBC驱动增强（如ShardingSphere-JDBC、TDDL）：替换应用的数据源驱动，在应用进程内完成路由。性能好、支持灵活策略（如强制走主库），但需升级依赖、对应用有一定侵入性。
• 应用层手动控制（Spring AbstractRoutingDataSource + AOP）：完全由业务代码决定读写库，最灵活也最可控。适合中小系统或对一致性要求极高的场景，但容易误用（比如在事务中读从库导致脏读）。

二、路由策略设计要点

不能所有读都扔给从库，必须结合业务语义判断是否可读从库：

• 强一致性读必须走主库：比如用户刚提交订单，紧接着查订单详情；或任何“写后即读”场景。可通过注解（如@Master）或线程上下文标记强制主库。
• 从库延迟容忍度要量化：监控从库复制延迟（Seconds_Behind_Master 或 GTID差值），超过阈值（如500ms）自动降级读主库，避免展示过期数据。
• 读请求打散与负载均衡：多个从库之间按权重轮询或根据响应时间动态调整，避免热点从库拖垮整体读性能。

三、业务接入关键改造项

无论选哪种技术方案，业务侧至少需明确以下几点：

标签： proxy 路由 热点