年后在进行腾讯二面的时候，写完算法的后问的第一个问题就是，MySQL的半同步是什么？我当时直接懵了，我以为是问的MySQL的两阶段提交的问题呢？结果确认了一下后不是两阶段提交，然后面试官看我连问的是啥都不知道，就直接跳过这个问题，直接聊下一个问题了。所以这次总结一下这部分的知识内容，文字内容比较多，可能会有些枯燥，但对于这方面感兴趣的人来说还是比较有意思的。
MySQL的主从复制我们的一般在大规模的项目上，都是使用MySQL的复制功能来创建MySQL的主从集群的。主要是可以通过为服务器配置一个或多个备库的方式来进行数据同步。复制的功能不仅有利于构建高性能应用，同时也是高可用、可扩展性、灾难恢复、备份以及数据仓库等工作的基础。
说的通俗一点，通过MySQL的主从复制来实现读写分离，相比单点数据库又读又写来说，提升了业务系统性能，优化了用户体验。另外通过主从复制实现了数据库的高可用，当主节点MySQL挂了的时候，可以用从库来顶上。
MySQL支持的复制方式MySQL支持三种复制方式：
基于语句的复制（也称为逻辑复制）主要是指，在主数据库上执行的SQL语句，在从数据库上会重复执行一遍。MySQL默认采用的就是这种复制，效率比较高。但是也是有一定的问题的，如果SQL中使用uuid()、rand()等函数，那么复制到从库的数据就会有偏差。
基于行的复制，指将更新处理后的数据复制到从数据库，而不是执行一边语句。从MySQL5.1的版本才被支持。
混合复制，默认采用语句复制，当发现语句不能进行精准复制数据时（例如语句中含有uuid()、rand()等函数），采用基于行的复制。
主从复制原理MySQL的复制原理概述上来讲大体可以分为这三步
在主库上把数据更改，记录到二进制日志（Binary Log）中。
从库将主库上的日志复制到自己的中继日志（Relay Log）中。
备库读取中继日志中的事件，将其重放到备库数据之上。
主要过程如下图：
下面来详细说一下复制的这三步：
第一步：是在主库上记录二进制日志，首先主库要开启binlog日志记录功能，并授权Slave从库可以访问的权限。这里需要注意的一点就是binlog的日志里的顺序是按照事务提交的顺序来记录的而非每条语句的执行顺序。
第二步：从库将binLog复制到其本地的RelayLog中。首先从库会启动一个工作线程，称为I/O线程，I/O线程跟主库建立一个普通的客户端连接，然后主库上启动一个特殊的二进制转储（binlog dump）线程，此转储线程会读取binlog中的事件。当追赶上主库后，会进行休眠，直到主库通知有新的更新语句时才继续被唤醒。
这样通过从库上的I/O线程和主库上的binlog dump线程，就将binlog数据传输到从库上的relaylog中了。
第三步：从库中启动一个SQL线程，从relaylog中读取事件并在备库中执行，从而实现备库数据的更新。
这种复制架构实现了获取事件和重放事件的解耦，运行I/O线程能够独立于SQL线程之外工作。但是这种架构也限制复制的过程，最重要的一点是在主库上并发运行的查询在备库中只能串行化执行，因为只有一个SQL线程来重放中继日志中的事件。
说到这个主从复制的串行化执行的问题，我就想到了一个之前在工作中遇到的一个问题，就是有这么一个业务场景，我们有一个操作是初始化一批数据，数据是从一个外部系统的接口中获取的，然后我是通过线程池里的多个线程并行从外部系统的接口中获取数据，每个线程获取到数据后，直接插入到数据库中。然后在数据全部入库完成后，然后去执行批量查询，将刚插入到数据库中的数据查询出来，放到ElasticSearch中。结果每次放入到ES中的数据总是不完整，后来研究了半天都不行，最终是让查询也走的主库才解决的问题。当时不知道是MySQL主从复制的串行化从而导致的这个问题。
MySQL主从复制模式MySQL的主从复制其实是支持，异步复制、半同步复制、GTID复制等多种复制模式的。
异步模式MySQL的默认复制模式就是异步模式，主要是指MySQL的主服务器上的I/O线程，将数据写到binlong中就直接返回给客户端数据更新成功，不考虑数据是否传输到从服务器，以及是否写入到relaylog中。在这种模式下，复制数据其实是有风险的，一旦数据只写到了主库的binlog中还没来得急同步到从库时，就会造成数据的丢失。