问题来了!腾讯二面中MySQL的半同步是什么？

前言 

年后在进行腾讯二面的时候，写完算法的后问的第一个问题就是，MySQL的半同步是什么？我当时直接懵了，我以为是问的MySQL的两阶段提交的问题呢？结果确认了一下后不是两阶段提交，然后面试官看我连问的是啥都不知道，就直接跳过这个问题，直接聊下一个问题了。所以这次总结一下这部分的知识内容，文字内容比较多，可能会有些枯燥，但对于这方面感兴趣的人来说还是比较有意思的。

MySQL的主从复制

我们的一般在大规模的项目上，都是使用MySQL的复制功能来创建MySQL的主从集群的。主要是可以通过为服务器配置一个或多个备库的方式来进行数据同步。复制的功能不仅有利于构建 高性能应用，同时也是高可用、可扩展性、灾难恢复、备份以及数据仓库等工作的基础 。

说得通俗一点，通过MySQL的主从复制来实现读写分离，相比单点数据库又读又写来说，提升了业务系统性能，优化了用户体验。另外通过主从复制实现了数据库的高可用，当主节点MySQL挂了的时候，可以用从库来顶上。

MySQL支持的复制方式

MySQL支持三种复制方式：

• 基于语句的复制（也称为逻辑复制）主要是指，在主数据库上执行的SQL语句，在从数据库上会重复执行一遍 。MySQL默认采用的就是这种复制，效率比较高。但是也是有一定的问题的，如果SQL中使用uuid()、rand()等函数，那么复制到从库的数据就会有偏差。
• 基于行的复制，指将更新处理后的数据复制到从数据库，而不是执行一边语句 。从MySQL5.1的版本才被支持。
• 混合复制，默认采用语句复制，当发现语句不能进行精准复制数据时（例如语句中含有uuid()、rand()等函数），采用基于行的复制 。

主从复制原理

MySQL的复制原理概述上来讲大体可以分为这三步

1. 在主库上把数据更改，记录到二进制日志（Binary Log）中。
2. 从库将主库上的日志复制到自己的中继日志（Relay Log）中。
3. 备库读取中继日志中的事件，将其重放到备库数据之上。

主要过程如下图：

下面来详细说一下复制的这三步：

第一步：是在主库上记录二进制日志，首先主库要开启binlog日志记录功能，并授权Slave从库可以访问的权限。这里需要注意的一点就是binlog的日志里的顺序是按照事务提交的顺序来记录的而非每条语句的执行顺序。

第二步：从库将binLog复制到其本地的RelayLog中。首先从库会启动一个工作线程，称为I/O线程，I/O线程跟主库建立一个普通的客户端连接，然后主库上启动一个特殊的二进制转储（binlog dump）线程，此转储线程会读取binlog中的事件。当追赶上主库后，会进行休眠，直到主库通知有新的更新语句时才继续被唤醒。

这样通过从库上的I/O线程和主库上的binlog dump线程，就将binlog数据传输到从库上的relaylog中了。

第三步：从库中启动一个SQL线程，从relaylog中读取事件并在备库中执行，从而实现备库数据的更新。

这种复制架构实现了获取事件和重放事件的解耦，运行I/O线程能够独立于SQL线程之外工作。但是这种架构也限制复制的过程，最重要的一点是在主库上并发运行的查询在备库中只能串行化执行，因为只有一个SQL线程来重放中继日志中的事件。

说到这个主从复制的串行化执行的问题，我就想到了一个之前在工作中遇到的一个问题，就是有这么一个业务场景，我们有一个操作是初始化一批数据，数据是从一个外部系统的接口中获取的，然后我是通过线程池里的多个线程并行从外部系统的接口中获取数据，每个线程获取到数据后，直接插入到数据库中。然后在数据全部入库完成后，然后去执