2、数据库高可用基础：主从复制原理（MySQL Binlog）、读写分离架构、常见复制拓扑

数据库高可用是分布式系统稳定性的基石。MySQL 主从复制通过二进制日志（Binlog）实现数据同步，是构建读写分离、故障转移、灾备恢复等架构的核心技术。本节从 Binlog 原理出发，逐步拆解复制流程、读写分离架构及常见拓扑。

2.1 MySQL Binlog 与主从复制原理

MySQL 主从复制基于 二进制日志（Binary Log，简称 Binlog） 实现。Binlog 记录了所有修改数据库数据的 DDL 和 DML 语句（除 SELECT 外），以事件形式顺序写入磁盘。主库将 Binlog 推送给从库，从库重放日志以保持数据一致。

2.1.1 复制核心流程（三步握手）

1. 主库（Master）：事务提交时，将数据变更写入 Binlog 文件，并记录当前日志位置（Position）。
2. 从库（Slave）：启动两个关键线程——I/O 线程 和 SQL 线程。I/O 线程连接主库，请求指定 Binlog 文件名和偏移量，主库的 Dump 线程 负责推送日志内容。
3. 从库重放：I/O 线程将接收到的 Binlog 事件写入本地的 中继日志（Relay Log）；SQL 线程顺序读取 Relay Log 并执行其中的 SQL 语句，完成数据同步。

2.1.2 Binlog 三种格式对比

2.2 读写分离架构

读写分离将数据库的读请求和写请求分发到不同的节点：主库（Master） 负责写入（INSERT/UPDATE/DELETE），从库（Slave） 负责读取（SELECT）。这种架构能有效分摊主库压力，提升系统吞吐量。

2.2.1 架构组件与数据流

• 负载均衡层：通常由代理中间件（如 ProxySQL、MyCat、MaxScale）或应用层路由实现，根据 SQL 类型自动分发请求。
• 主库：处理写请求，同时将 Binlog 推送给所有从库。
• 从库：处理读请求，可水平扩展以提升读能力。
• 延迟监控：从库可能因主从延迟读到旧数据，需配合 强制读主 或 延迟阈值 策略。

2.2.2 读写分离架构图

2.3 常见复制拓扑

根据业务规模、可用性要求和成本，MySQL 主从复制有多种拓扑结构。以下为三种最常用的模式。

2.3.1 一主一从

最简单的拓扑：一个主库对应一个从库。从库作为主库的备份，同时承担读流量。适用于小型应用、开发测试环境或对可用性要求不高的场景。

• 优点：部署简单，维护成本低。
• 缺点：主库故障时，从库提升为主库期间存在写不可用窗口；读能力扩展有限。

2.3.2 一主多从

一个主库对应多个从库。从库可水平扩展，大幅提升读能力。适用于读多写少、报表查询、数据分析等场景。

• 优点：读能力线性扩展；多个从库可分担不同业务查询（如一个从库做实时查询，另一个做离线分析）。
• 缺点：主库写入压力不变；主库故障时，需从多个从库中选举新主库，流程复杂。

2.3.3 双主（Master-Master）与级联复制

双主架构：两个节点互为主从，均可读写。需解决冲突问题（如自增 ID 偏移、应用层拆分写入）。级联复制：从库再挂载从库，形成树状结构，用于跨机房、跨地域的数据同步。

2.4 常见复制拓扑图