📚 课程目录第3章主从复制架构原理

3. 主从复制架构原理：异步复制、半同步复制、全同步复制

聊高可用设计，绕不开主从复制。说白了，就是主库写数据，从库同步数据。但同步的这个过程，到底是快是慢、是准是稳，直接决定了你的系统在面对故障时能扛多久、丢多少数据。

我见过不少团队，一上来就拍板用异步复制，理由是性能好。结果一次主库宕机，从库数据落后好几秒，恢复之后直接丢了一批交易。那时候你才意识到，选错复制模式，比选错数据库还致命。

今天我就把三种主流的主从复制模式掰开讲清楚：异步复制、半同步复制、全同步复制。它们各自的原理、优缺点、适用场景，我都会结合项目中的实际案例来分析。

3.1 异步复制：性能至上，但有代价

异步复制，原理很简单：主库写完事务后，直接返回成功，不等待从库确认。发送binlog或WAL日志到从库的过程，在后台异步进行。

特性	说明
主库写入延迟	最低，主库不等待从库
数据一致性	最终一致性，主从可能存在延迟
故障恢复	主库宕机，可能丢失未同步数据
典型应用	MySQL默认复制模式、Redis主从

这个模式的优点是性能极好。主库不会被从库「拖后腿」。你想想看，在流量高峰期，每多一次网络往返，延迟就多几毫秒，积少成多就是灾难。

⚠ 我曾经在一个金融项目中「翻过车」。当时采用MySQL异步复制，主库硬件故障，部分binlog还没来得及传给从库就物理损坏了。恢复后，我们丢失了约3秒的交易数据。事后复盘，核心原因就是异步复制无法保证「数据不丢」。

我个人习惯把异步复制比作「寄信不挂号」——你写了信扔进邮筒，至于对方收没收到，你不关心，也管不着。速度快，但不可靠。

适用场景：对数据丢失容忍度较高的业务，比如日志采集、用户行为分析、缓存预热等。核心交易、资金流水，谨慎使用。

3.2 半同步复制：一个折衷的好选择

半同步复制，我理解为「既要又要」的方案。主库写完事务后，必须等待至少一个从库确认接收日志，才返回成功给客户端。但注意，它只等「接收」，不等「应用」。也就是说，从库拿到日志就算完事，不要求从库已经写入数据文件。

这样做的好处很明显：主库数据与从库日志之间，几乎没有差距。一旦主库宕机，从库至少持有完整的日志，可以立即接管。


-- MySQL开启半同步复制的示例配置
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_master_enabled = 1;
SET GLOBAL rpl_semi_sync_slave_enabled = 1;

我建议你在核心业务场景中优先考虑半同步复制。比如用户认证、订单主数据、账户余额等。这些场景数据一致性要求高，同时不能忍受异步复制那样的数据丢失风险。

对比项	异步复制	半同步复制
数据零丢失	可能丢失	最多丢一个事务窗口
写入延迟	无额外延迟	增加一次网络往返
性能影响	几乎无影响	轻微影响，可接受
恢复时间	需检查数据完整性	可直接切换

有一种常见的坑：半同步复制并不是「安全」。如果在等待从库ACK的过程中，主库和所有从库同时宕机，数据仍然可能丢失。但这种情况概率极低，可以接受。

3.3 全同步复制：安全第一，性能代价

全同步复制，是安全至上的方案。主库写完事务后，必须等待所有从库都确认接收并应用日志，才返回成功。我习惯叫它「全员签字」模式。

这种模式的保证最强：任何一个节点写入成功，所有节点都持有最新数据。主库宕机？从库直接顶上，数据零丢失。

我曾经帮某银行设计密钥管理系统，他们要求「在任何单个节点故障下，不丢失任何一笔交易」。我们最终选择了全同步复制，配合Paxos共识协议。代价是写入吞吐量下降约50%，但换来了的灾备能力。

但问题也很显然：慢。主库的每一次写操作，都要等节点确认。网络延迟、节点负载、磁盘IO，任何一环出现问题，写操作都会被拖死。

另外要注意，全同步复制在跨数据中心部署时，网络延迟会成为不可忽视的瓶颈。你想想看，北京写一条数据，要等深圳、上海、硅谷的机器都回复ACK，几百毫秒就过去了。

对比项	半同步复制	全同步复制
等待节点数	至少1个从库	全部从库
数据零丢失	几乎	完全保证
性能损耗	低	高
适用场景	交易、支付、认证	密钥管理、金融清算

全同步复制更适合三种场景：第一，密钥管理系统、根CA、支付清算等需要一致的系统；第二，节点数较少且网络稳定的内网集群；第三，监管或合规要求明确「数据不丢」的场景。


// 伪代码：全同步复制的主库写入流程
function write(data):
    writeToLocal(data)
    for slave in allSlaves:
        sendLogToSlave(slave)
    for slave in allSlaves:
        waitForSlaveAck(slave, timeout)
    if allAckReceived:
        return SUCCESS
    else:
        rollback()  // 超时或失败则回滚
        return FAILURE

嗯，这里要注意：全同步复制的超时策略要设置合理。超时太短，网络抖动就回滚，业务吞吐量急剧下降；超时太长，故障节点拖死整个集群。我建议超时配置在3-5秒，并配合自动剔除故障节点的机制。

3.4 三种复制模式的对比与选择

为了让你更直观地做技术选型，我画了一张对比图，把三种模式放在一起看，优劣一目了然。

💡 我个人习惯在技术方案评审时，先用一张对比表把这三种模式列出来，再结合业务对「RPO（恢复点目标）」和「RTO（恢复时间目标）」的要求做选择。如果业务方说「数据不能丢」，你至少要选半同步复制；如果说「一分钱都不能差」，那只能上全同步复制。

实际上，现在很多数据库系统都支持运行时动态调整复制模式。比如MySQL可以通过rpl_semi_sync_master_timeout参数控制半同步的超时回退。如果从库ACK超时，自动降级为异步复制。这样既保证了可用性，又不至于让单节点故障拖垮整个集群。

不过要小心，降级机制引入了一个新问题：当从库恢复正常时，主库已经以异步模式运行了一段时间，两者之间可能存在数据缺口。恢复后需要手工或自动补偿数据。这个逻辑在密钥服务中尤其要谨慎，密钥的版本号和序列号一旦出现空洞，后续的加密、解密、验签都可能产生不一致的结果。