从库有了，流量怎么分
一主两从搭完，读写分离是必然动作，但「写主读从」四个字后面藏着两套完全不同的落地路线；而主库单点问题（第 8 篇哨兵篇的老朋友，数据库这边也有同款考题）要用高可用方案来答。这篇把两道题一起答完。
路由方案：应用层 vs 代理层
| 方案 | 代表 | 优点 | 缺点 |
|---|---|---|---|
| 应用层路由 | ShardingSphere-JDBC、Spring 多数据源 + AbstractRoutingDataSource | 无中间件、少一跳延迟；代码里可精细控制 | 每个应用都要配；语言绑定，跨团队难统一 |
| 代理层 | ProxySQL、ShardingSphere-Proxy、MaxScale | 对应用透明，集中管控；平滑扩从库 | 多一跳延迟；代理自身要高可用；SQL 兼容面要验证 |
选型经验：中小规模、Java 技术栈统一，应用层够用且省心；多语言并存、要集中治理连接和查询时上代理。老王选的应用层——他的场景一个 Spring Boot 项目说了算，别给自己加一跳。
强制走主库的三个场景
- 写后立读：同一请求内改完立刻读（改昵称刷新资料页）——第 12 篇的延迟问题，路由层按「用户 + 短时间窗」粘主库；
- 强一致读：余额、库存、支付状态这类决策性读，永远主库；
- 事务内：事务里的读必须和写同源，路由组件要感知事务上下文。
别的都往从库放——读写分离的正确姿势不是「能读从就读从」，而是「不能读从的绝不读从」，白名单思路反着来才不会翻车。
高可用选型：MHA、Orchestrator 与 MGR
主库挂了，要有人完成三件事：识别故障、选出新主、把流量切过去——这就是 Failover。三个主流候选：
| 方案 | 原理 | 特点 |
|---|---|---|
| MHA | 外置管理节点监控主库，故障时补齐从库差量再选新主 | 老牌经典；最大程度减少数据丢失；管理节点自身单点，社区活跃度下降 |
| Orchestrator | 拓扑感知的自动化 Failover 与可视化 | 拓扑发现、人工/自动切换都好用；需与 ProxSQL 等配合做流量切换 |
| MGR | 组复制，基于 Paxos 多数派表决提交，自带选主 | 数据库原生方案，RPO≈0 不丢事务；要求较高（每行要有主键、写入吞吐受限），运维心智新 |
再给一张决断表：
| 场景 | 建议 |
|---|---|
| 读多写少的业务库，容忍秒级切换 | 主从 + Orchestrator / MHA，务实性价比 |
| 交易核心库，绝不丢事务 | MGR（或半同步 + Orchestrator 兜底） |
| 云上部署 | 直接用云数据库的高可用版（RDS 主备），别重复造轮子 |
和 Redis 哨兵篇的结论遥相呼应：单点不能拍板，但人数也不能太多——MGR 的多数派要求奇数节点，故障切换的「投票委员会」逻辑在两个体系里一模一样。
到这，主从三部曲收官：搭建（11）、延迟（12）、路由与切换（13）。下一篇转向性能调优的服务器视角：Buffer Pool 为什么是 MySQL 的命根子、核心参数怎么给。
咖啡凉了，记得趁热喝。
评论 (0)