2. 主从架构基础：主节点与从节点的角色定义、数据同步机制（异步/半同步/同步）、读写分离模型
2.1 主节点与从节点的角色定义
在主从复制架构中，数据库实例被划分为两种核心角色：主节点（Primary/Master）与从节点（Replica/Slave）。两者职责明确，协同保障数据的高可用与读写负载分离。
| 角色 | 核心职责 | 可读写 | 故障影响范围 |
|---|---|---|---|
| 主节点 | 处理所有写操作（INSERT / UPDATE / DELETE）；生成二进制日志（binlog）；维护数据一致性源头 | 读写均可 | 主节点故障 → 写服务中断，需触发主从切换 |
| 从节点 | 通过 I/O 线程拉取主节点 binlog，由 SQL 线程回放；提供只读查询能力；可承担备份、报表、分析等负载 | 只读（通常配置 read_only=1） | 单从节点故障 → 读能力降级，不影响写服务 |
生产建议：从节点务必设置
read_only=1 并禁止 super 用户直接写入，防止因误操作导致主从数据不一致。
2.2 数据同步机制：异步 / 半同步 / 同步
主从复制的核心在于主节点将数据变更传递到从节点。根据主节点等待从节点确认的强度，分为三种同步模式，直接影响数据安全与写入性能。
2.2.1 异步复制（Asynchronous Replication）
- 流程：主节点提交事务并写入 binlog 后，立即返回客户端成功，不等待从节点确认。
- 优点：写入延迟最低，主节点性能不受从节点影响。
- 缺点：主节点宕机时，已提交但尚未传输到从节点的事务将永久丢失（RPO > 0）。
- 适用场景：对数据一致性要求不高、允许少量数据丢失的报表或日志库。
2.2.2 半同步复制（Semi-Synchronous Replication）
- 流程：主节点提交事务后，等待至少一个从节点确认已收到 binlog 并写入 relay log，再返回客户端成功。
- 优点：主节点故障时，至少有一个从节点拥有最新数据，RPO 趋近于零。
- 缺点：写入延迟略有增加（取决于网络 RTT）；若从节点超时未确认，自动降级为异步复制。
- 适用场景：金融、交易等对数据一致性要求较高的核心业务。
2.2.3 同步复制（Synchronous Replication）
- 流程：主节点等待所有从节点确认写入 relay log 后，才返回客户端成功。
- 优点：主从数据完全一致，RPO = 0。
- 缺点：写入延迟受最慢从节点影响；任一从节点故障将阻塞主节点写入，降低整体可用性。
- 适用场景：极少使用，仅在强一致性要求极高且从节点极少（如 1 个）的特定场景下考虑。
关键参数提醒：MySQL 半同步复制通过插件
rpl_semi_sync_master 和 rpl_semi_sync_slave 启用。超时参数 rpl_semi_sync_master_timeout 默认 10 秒，生产环境建议调整为 1000~3000ms，避免因网络抖动导致频繁降级。
2.3 读写分离模型
读写分离是主从架构最核心的应用模式：将写流量路由到主节点，将读流量分散到多个从节点，从而提升系统整体吞吐能力。
2.3.1 读写分离的实现方式
| 实现方式 | 描述 | 优点 | 缺点 |
|---|---|---|---|
| 应用层硬编码 | 在业务代码中区分数据源，写操作连接主库，读操作连接从库 | 实现简单，无需额外组件 | 代码侵入性强，维护成本高 |
| 中间件代理 | 通过 Proxy（如 ProxySQL、MyCat、MaxScale）自动解析 SQL 并路由 | 对业务透明，支持负载均衡、故障转移 | 引入额外网络延迟，需运维中间件 |
| JDBC 驱动层 | 使用支持读写分离的 JDBC 驱动（如 MySQL Connector/J 的 ReplicationDriver） | 轻量级，无需独立部署 | 功能有限，复杂路由策略支持不足 |
2.3.2 读写分离的延迟处理策略
- 强制读主：对一致性要求极高的操作（如支付后立即查询余额），在请求中标记强制路由到主节点。
- 延迟阈值控制：监控从节点
Seconds_Behind_Master，延迟超过阈值（如 5 秒）时自动摘除该从节点读流量。 - 会话级一致性：在写操作后，将当前会话的后续读请求绑定到主节点，直到事务结束或超时。
最佳实践：在自助服务变更窗口的主从切换场景中，建议采用 半同步复制 + 中间件代理 的组合方案。半同步保障数据安全，中间件实现自动读写分离与故障转移，降低切换对业务的影响。