惊险，腾讯二面差点死在这个问题上：MySQL的半同步，2024年最新java相关的面试题

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

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线程来重放中继日志中的事件。

说到这个主从复制的串行化执行的问题，我就想到了一个之前在工作中遇到的一个问题，就是有这么一个业务场景，我们有一个操作是初始化一批数据，数据是从一个外部系统的接口中获取的，然后我是通过线程池里的多个线程并行从外部系统的接口中获取数据，每个线程获取到数据后，直接插入到数据库中。然后在数据全部入库完成后，然后去执行批量查询，将刚插入到数据库中的数据查询出来，放到ElasticSearch中。结果每次放入到ES中的数据总是不完整，后来研究了半天都不行，最终是让查询也走的主库才解决的问题。当时不知道是MySQL主从复制的串行化从而导致的这个问题。

MySQL主从复制模式

===========

MySQL的主从复制其实是支持， 异步复制 、 半同步复制 、 GTID复制 等多种复制模式的。

异步模式

====

MySQL的默认复制模式就是异步模式，主要是 指MySQL的主服务器上的I/O线程，将数据写到binlong中就直接返回给客户端数据更新成功，不考虑数据是否传输到从服务器，以及是否写入到relaylog中 。在这种模式下，复制数据其实是有风险的，一旦数据只写到了主库的binlog中还没来得及同步到从库时，就会造成数据的丢失。

但是这种模式确也是效率最高的，因为变更数据的功能都只是在主库中完成就可以了，从库复制数据不会影响到主库的写数据操作。

上面我也说了，这种异步复制模式虽然效率高，但是数据丢失的风险很大，所以就有了后面要介绍的半同步复制模式。

半同步模式

=====

MySQL从 5.5 版本开始通过以插件的形式开始支持半同步的主从复制模式。什么是半同步主从复制模式呢？

这里通过对比的方式来说明一下：

• 异步复制模式 ：上面我们已经介绍了，异步复制模式，主库在执行完客户端提交的事务后，只要将执行逻辑写入到binlog后，就立即返回给客户端，并不关心从库是否执行成功，这样就会有一个隐患，就是在主库执行的binlog还没同步到从库时，主库挂了，这个时候从库就就会被强行提升为主库，这个时候就有可能造成数据丢失。

• 同步复制模式 ：当主库执行完客户端提交的事务后，需要等到所有从库也都执行完这一事务后，才返回给客户端执行成功。因为要等到所有从库都执行完，执行过程中会被阻塞，等待返回结果，所以性能上会有很严重的影响。

• 半同步复制模式 ：半同步复制模式，可以说是介于异步和同步之间的一种复制模式，主库在执行完客户端提交的事务后，要等待至少一个从库接收到binlog并将数据写入到relay log中才返回给客户端成功结果。半同步复制模式，比异步模式提高了数据的可用性，但是也产生了一定的性能延迟，最少要一个TCP/IP连接的往返时间。

半同步复制模式，可以很明确的知道，在一个事务提交成功之后，此事务至少会存在于两个地方一个是主库一个是从库中的某一个。 主要原理是，在master的dump线程去通知从库时，增加了一个ACK机制，也就是会确认从库是否收到事务的标志码，master的dump线程不但要发送binlog到从库，还有负责接收slave的ACK。当出现异常时，Slave没有ACK事务，那么将自动降级为异步复制，直到异常修复后再自动变为半同步复制

MySQL半同步复制的流程如下：

半同步复制的隐患

========

半同步复制模式也存在一定的数据风险，当事务在主库提交完后等待从库ACK的过程中，如果Master宕机了，这个时候就会有两种情况的问题。

• 事务还没发送到Slave上 ：若事务还没发送Slave上，客户端在收到失败结果后，会重新提交事务，因为重新提交的事务是在新的Master上执行的，所以会执行成功，后面若是之前的Master恢复后，会以Slave的身份加入到集群中，这个时候，之前的事务就会被执行两次，第一次是之前此台机器作为Master的时候执行的，第二次是做为Slave后从主库中同步过来的。

• 事务已经同步到Slave上 ：因为事务已经同步到Slave了，所以当客户端收到失败结果后，再次提交事务，你那么此事务就会在当前Slave机器上执行两次。

为了解决上面的隐患，MySQL从5.7版本开始，增加了一种新的半同步方式。新的半同步方式的执行过程是将“ Storage Commit ”这一步移动到了“ Write Slave dump ”后面。这样保证了 只有Slave的事务ACK后，才提交主库事务 。MySQL 5.7.2版本新增了一个参数来进行配置：

rpl_semi_sync_master_wait_point ，此参数有两个值可配置：

• AFTER_SYNC ：参数值为AFTER_SYNC时，代表采用的是新的半同步复制方式。

• AFTER_COMMIT ：代表采用的是之前的旧方式的半同步复制模式。

MySQL从5.7.2版本开始，默认的半同步复制方式就是 AFTER_SYNC 方式了，但是方案不是万能的，因为 AFTER_SYNC 方式是在事务同步到Slave后才提交主库的事务的，若是当主库等待Slave同步成功的过程中Master挂了，这个Master事务提交就失败了，客户端也收到了事务执行失败的结果了，但是Slave上已经将binLog的内容写到Relay Log里了，这个时候，Slave数据就会多了，但是多了数据一般问题不算严重，多了总比少了好。MySQL，在没办法解决分布式数据一致性问题的情况下，它能保证的是不丢数据，多了数据总比丢数据要好。

这里说几个的半同步复制模式的参数：

mysql> show variables like ‘%Rpl%’;

±------------------------------------------±-----------+

| Variable_name | Value |

±------------------------------------------±-----------+

| rpl_semi_sync_master_enabled | ON |

| rpl_semi_sync_master_timeout | 10000 |

| rpl_semi_sync_master_trace_level | 32 |

| rpl_semi_sync_master_wait_for_slave_count | 1 |

| rpl_semi_sync_master_wait_no_slave | ON |

| rpl_semi_sync_master_wait_point | AFTER_SYNC |

| rpl_stop_slave_timeout | 31536000 |

±------------------------------------------±-----------+

– 半同步复制模式开关

rpl_semi_sync_master_enabled

– 半同步复制，超时时间，单位毫秒，当超过此时间后，自动切换为异步复制模式

rpl_semi_sync_master_timeout

– MySQL 5.7.3引入的，该变量设置主需要等待多少个slave应答，才能返回给客户端，默认为1。

rpl_semi_sync_master_wait_for_slave_count

– 此值代表当前集群中的slave数量是否还能够满足当前配置的半同步复制模式，默认为ON，当不满足半同步复制模式后，全部Slave切换到异步复制，此值也会变为OFF

rpl_semi_sync_master_wait_no_slave

– 代表半同步复制提交事务的方式，5.7.2之后，默认为AFTER_SYNC

rpl_semi_sync_master_wait_point

GTID模式

======

MySQL从5.6版本开始推出了GTID复制模式，GTID即全局事务ID (global transaction identifier)的简称，GTID是由UUID+TransactionId组成的，UUID是单个MySQL实例的唯一标识，在第一次启动MySQL实例时会自动生成一个server_uuid, 并且默认写入到数据目录下的auto.cnf(mysql/data/auto.cnf)文件里。TransactionId是该MySQL上执行事务的数量，随着事务数量增加而递增。这样保证了 GTID在一组复制中，全局唯一 。

这样通过GTID可以清晰地看到，当前事务是从哪个实例上提交的，提交的第多少个事务。

来看一个GTID的具体形式：

mysql> show master status;

±----------±---------±-------------±-----------------±------------------------------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

±----------±---------±-------------±-----------------±------------------------------------------+

| on.000003 | 187 | | | 76147e28-8086-4f8c-9f98-1cf33d92978d:1-322|

±----------±---------±-------------±-----------------±------------------------------------------+

1 row in set (0.00 sec)

GTID：76147e28-8086-4f8c-9f98-1cf33d92978d:1-322

UUID：76147e28-8086-4f8c-9f98-1cf33d92978d

TransactionId:1-322

GTID的工作原理

=========

由于GTID在一组主从复制集群中的唯一性，从而保证了每个GTID的事务只在一个MySQL上执行一次。

总结

阿里伤透我心，疯狂复习刷题，终于喜提offer 哈哈~好啦，不闲扯了

1、JAVA面试核心知识整理（PDF）：包含JVM，JAVA集合，JAVA多线程并发，JAVA基础，Spring原理，微服务，Netty与RPC，网络，日志，Zookeeper，Kafka，RabbitMQ，Hbase，MongoDB，Cassandra，设计模式，负载均衡，数据库，一致性哈希，JAVA算法，数据结构，加密算法，分布式缓存，Hadoop，Spark，Storm，YARN，机器学习，云计算共30个章节。

2、Redis学习笔记及学习思维脑图

3、数据面试必备20题+数据库性能优化的21个最佳实践

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

化的21个最佳实践

[外链图片转存中…(img-0JcX1vzS-1713706639546)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-cGQFgIAk-1713706639546)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！