MySQL主从同步一致性是大型架构的关键点，也是大厂重点考察内容，下面我就全面来详解MySQL主从一致性方案@mikechen
本篇已收于mikechen原创超30万字《阿里架构师进阶专题合集》里面。
MySQL主从异步复制
异步复制（Asynchronous Replication）， 是MySQL的默认复制模式。
采用异步复制，在提交事务时，主服务器将事务日志写入(Binary Log)，然后立即返回成功的响应，不等待从服务器的确认。
如下图所示：
工作流程：
- 主服务器执行事务操作，并将事务写入(Binary Log)；
- 主服务器将（Binary Log），传递到从服务器；
- 从服务器将（Binary Log）写入到Relay Log，并将日志应用到数据库中；
- 主服务器在事务提交后立即返回成功，不等待从服务器的确认。
在MySQL的异步复制模式中，虽然性能较高，但也带来了一些一致性问题。
原因很简单，由于异步复制模式下，主服务器提交事务后，不需要等待从服务器的确认，因此从服务器可能会滞后于主服务器一段时间。
例如：从服务器上的查询可能会返回过时的数据，而主服务器上的写操作，可能未在从服务器上反映。
再比如：如果主服务器在从服务器接收到最新事务之前发生故障，未复制的数据可能会丢失。
所以，这种模式性能较高，但会涉及到数据不一致的问题，这就会涉及到另外方案，比如：半同步、和全同步方案。
MySQL半同步复制
采用半同步复制模式，它是在主服务器提交事务时，至少等待一个从服务器确认接收到日志，从而减少数据丢失的风险。
如下图所示：
工作流程，大致如下：
第一步：事务提交
首先，主服务器在执行事务时，将事务操作写入自己的 Binary Log（二进制日志）；
第二步：日志传输
然后，主服务器将 Binary Log 中的事务数据，发送到从服务器；
第三步：确认传输
半同步复制模式，要求主服务器在提交事务时，至少等待一个从服务器确认已经接收到事务日志。
一旦从服务器接收到日志并成功写入 Relay Log，它会向主服务器发送一个确认信号。
第四步：事务提交
主服务器在收到从服务器的确认信号后，才会完成事务的提交，这种机制减少了主从数据不一致的风险。
这种方式，比异步复制提供更高的数据一致性，因为主服务器至少需要等待一个从服务器确认接收了日志。
即使主服务器发生故障，已确认接收到日志的从服务器，可以保持较高的一致性。
但是，也会有部分的数据丢失，如果从服务器是“多个节点”的情况，这就需要考虑到：全同步复制。
MySQL全同步复制
全同步复制，很容易理解，就是必须把所有从节点的数据同步完，才能返回。
如下图所示：
大致，工作流程如下：
- 主服务器执行事务操作，并将事务写入（Binary Log）；
- 然后，主服务器将（Binary Log）传递到所有从服务器；
- 每个从服务器将（Binary Log）写入Relay Log，并将其应用到数据库中。
- 从服务器向主服务器发送确认消息，表示日志已经被应用。
- 主服务器，在接收到所有从服务器的确认消息后才认为事务提交完成。
这种方式，是最高级别的数据一致性，确保所有服务器的数据始终一致。
优点是数据一致性高，同样，缺点也是非常明显，就是性能开销大，因为主服务器需要等待所有从服务器的确认。
每种复制模式都有其适用场景，选择合适的模式取决于系统对数据一致性、和性能的要求。
本篇已收于mikechen原创超30万字《阿里架构师进阶专题合集》里面。
