4. 数据库高可用：主从复制、读写分离、MHA与Orchestrator、MySQL Group Replication

数据库高可用，说白了就是让 MySQL 在挂了的时候还能继续干活。我做了这么多年风控系统，见过太多因为数据库宕机导致整个业务瘫痪的案例。嗯，今天咱们就聊聊这个话题。

4.1 主从复制：高可用的基石

主从复制是 MySQL 高可用的基础。它的原理其实很简单：主库（Master）把数据变更记录到二进制日志（binlog）里，从库（Slave）拉取这些日志，然后在自己身上重放一遍。

我个人习惯把主从复制分成三个步骤：

• 主库提交事务：写入 binlog
• 从库拉取日志：I/O 线程把 binlog 拉到本地 relay log
• 从库重放日志：SQL 线程执行 relay log 中的 SQL

这里有个坑，我在项目中遇到过。如果从库的 SQL 线程执行速度跟不上主库的写入速度，就会出现主从延迟。风控系统对实时性要求很高，延迟几秒钟可能就会导致重复放款或者漏掉风险交易。

4.2 读写分离：分摊压力的利器

读写分离，说白了就是把写操作（INSERT/UPDATE/DELETE）发给主库，读操作（SELECT）发给从库。这样主库的压力就小多了。

你想想看，风控系统的查询量通常是写入量的几十倍。每次用户请求进来，我们要查黑名单、查历史交易、查设备指纹……全是读操作。如果都压在主库上，主库迟早要崩。

我常用的读写分离方案有两种：

• 应用层实现：在代码里配置两个数据源，写操作走主库，读操作走从库。简单直接，但需要改代码。
• 中间件实现：用 MyCat、ShardingSphere 或者 ProxySQL 这类中间件，自动路由 SQL。我个人更推荐这种方式，对业务代码无侵入。

4.3 MHA：老牌高可用方案

MHA（Master High Availability）是 MySQL 高可用的经典方案。它的核心逻辑是：当主库挂了，MHA 会选一个从库作为新主库，然后把其他从库指向新主库。

MHA 的工作流程大致如下：

1. 监控主库健康状态
2. 主库宕机后，选一个数据最新的从库
3. 把选中的从库提升为主库
4. 其他从库重新指向新主库
5. 应用端切换连接

MHA 的优点是成熟稳定，很多大厂都在用。但缺点也很明显：它需要额外的管理节点，而且切换过程中会有几十秒的不可用时间。

4.4 Orchestrator：更现代的选择

Orchestrator 是近几年流行起来的 MySQL 高可用管理工具。相比 MHA，它更轻量，而且支持自动故障检测和恢复。

我个人更喜欢 Orchestrator，原因有三：

• 自动发现拓扑：它能自动发现 MySQL 集群中的主从关系，不需要手动配置
• 可视化界面：有 Web UI，可以直观地看到集群状态
• 故障恢复更智能：它会根据数据一致性、延迟等因素，选择最优的恢复策略

我在项目中用 Orchestrator 替换了 MHA，切换时间从原来的 30 秒降到了 5 秒以内。嗯，这个提升还是很明显的。

4.5 MySQL Group Replication：原生高可用

MySQL Group Replication（MGR）是 MySQL 5.7 开始引入的原生高可用方案。它基于 Paxos 协议，实现了多节点写入和自动故障切换。

MGR 有两种模式：

模式	特点	适用场景
单主模式	只有一个节点可写，其他节点只读	兼容性要求高，不想改代码
多主模式	所有节点都可写，自动冲突检测	写入压力大，需要水平扩展

MGR 最大的优势是原生支持，不需要额外组件。但它的限制也不少：

• 所有节点必须使用 InnoDB 引擎
• 网络延迟要求高，建议在同一个机房部署
• 不支持外键和全局锁

4.6 如何选择？

说了这么多，到底该选哪个方案？我根据自己的经验，给个参考：

• 小规模系统（几十台）：用 MHA 或者 Orchestrator，简单稳定
• 中大规模系统（几百台）：用 Orchestrator + 读写分离中间件
• 追求极致高可用：用 MGR 单主模式，配合 Orchestrator 做二次保障

说白了，没有完美的方案，只有最适合你的方案。风控系统对数据一致性要求极高，我个人建议优先考虑 MGR 单主模式，配合 Orchestrator 做故障切换。这样既保证了数据一致性，又实现了自动恢复。

好了，数据库高可用这块就聊这么多。记住一点：没有银弹，只有权衡。根据你的业务场景、团队能力和预算，选择最合适的方案。

---

公众号:蓝海资料掘金营，微信deep3321