MySQL主从同步一致性是大型架构的关键点，也是大厂重点考察内容，下面我就全面来详解MySQL主从一致性方案@mikechen

本篇已收于mikechen原创超30万字《阿里架构师进阶专题合集》里面。

MySQL主从异步复制

异步复制（Asynchronous Replication）， 是MySQL的默认复制模式。

采用异步复制，在提交事务时，主服务器将事务日志写入(Binary Log)，然后立即返回成功的响应，不等待从服务器的确认。

如下图所示：

工作流程：

1. 主服务器执行事务操作，并将事务写入(Binary Log)；
2. 主服务器将（Binary Log），传递到从服务器；
3. 从服务器将（Binary Log）写入到Relay Log，并将日志应用到数据库中；
4. 主服务器在事务提交后立即返回成功，不等待从服务器的确认。

在MySQL的异步复制模式中，虽然性能较高，但也带来了一些一致性问题。

原因很简单，由于异步复制模式下，主服务器提交事务后，不需要等待从服务器的确认，因此从服务器可能会滞后于主服务器一段时间。

例如：从服务器上的查询可能会返回过时的数据，而主服务器上的写操作，可能未在从服务器上反映。

再比如：如果主服务器在从服务器接收到最新事务之前发生故障，未复制的数据可能会丢失。

所以，这种模式性能较高，但会涉及到数据不一致的问题，这就会涉及到另外方案，比如：半同步、和全同步方案。

MySQL半同步复制

采用半同步复制模式，它是在主服务器提交事务时，至少等待一个从服务器确认接收到日志，从而减少数据丢失的风险。

如下图所示：

工作流程，大致如下：

第一步：事务提交

首先，主服务器在执行事务时，将事务操作写入自己的 Binary Log（二进制日志）；

第二步：日志传输

然后，主服务器将 Binary Log 中的事务数据，发送到从服务器；

第三步：确认传输

半同步复制模式，要求主服务器在提交事务时，至少等待一个从服务器确认已经接收到事务日志。

一旦从服务器接收到日志并成功写入 Relay Log，它会向主服务器发送一个确认信号。

第四步：事务提交

主服务器在收到从服务器的确认信号后，才会完成事务的提交，这种机制减少了主从数据不一致的风险。

这种方式，比异步复制提供更高的数据一致性，因为主服务器至少需要等待一个从服务器确认接收了日志。

即使主服务器发生故障，已确认接收到日志的从服务器，可以保持较高的一致性。

但是，也会有部分的数据丢失，如果从服务器是“多个节点”的情况，这就需要考虑到：全同步复制。

MySQL全同步复制

全同步复制，很容易理解，就是必须把所有从节点的数据同步完，才能返回。

如下图所示：

大致，工作流程如下：

• 主服务器执行事务操作，并将事务写入（Binary Log）；
• 然后，主服务器将（Binary Log）传递到所有从服务器；
• 每个从服务器将（Binary Log）写入Relay Log，并将其应用到数据库中。
• 从服务器向主服务器发送确认消息，表示日志已经被应用。
• 主服务器，在接收到所有从服务器的确认消息后才认为事务提交完成。

这种方式，是最高级别的数据一致性，确保所有服务器的数据始终一致。

优点是数据一致性高，同样，缺点也是非常明显，就是性能开销大，因为主服务器需要等待所有从服务器的确认。

每种复制模式都有其适用场景，选择合适的模式取决于系统对数据一致性、和性能的要求。

本篇已收于mikechen原创超30万字《阿里架构师进阶专题合集》里面。