一直搞不清楚什么是读写分离，主从复制的原理，今天总算搞懂了

最新推荐文章于 2024-07-11 15:47:11 发布

爱开发V

最新推荐文章于 2024-07-11 15:47:11 发布

阅读量1.6k

点赞数

本文链接：https://blog.csdn.net/X8i0Bev/article/details/106631741

版权

作为一名java程序员，求职面试时时常会遇到类似这样的问题：

你有没有做过MySQL读写分离？
如何实现MySQL的读写分离？
说说MySQL主从复制原理？
如何解决 MySQL主从同步延时问题？

1、MySQL的读写分离

说到读写分离，我们先了解下什么是主从复制。

主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库，主数据库一般是准实时的业务数据库。一台服务器充当主服务器，而另外一台服务器充当从服务器。

此时主服务器会将更新信息写入到一个特定的二进制文件中，并会维护文件的一个索引用来跟踪日志循环，这个日志可以记录并发送到从服务器的更新中去。

一台从服务器连接到主服务器时，从服务器会通知主服务器从服务器的日志文件中读取最后一次成功更新的位置。然后从服务器会接收从哪个时刻起发生的任何更新，然后锁住并等到主服务器通知新的更新。

读写分离简单俩说就是基于主从复制架构，一个主库，有多个从库，主库主要负责写，写完后主库会自动把数据给同步给从库。

主从复制.jpg

2、MySQL主从复制的原理

MySQL主从复制实际上基于二进制日志，原理可以用一张图来表示：

主库将变更写入binlog日志，然后从库连接到主库之后，从库有一个 IO 线程，将主库的 binlog 日志拷贝到自己本地，写入一个 relay中继日志(relay log)中。接着从库中有一个SQL线程会从中继日志读取binlog，然后执行binlog日志中的内容，也就是在自己本地再次执行一遍SQL语句，从而使从服务器和主服务器的数据保持一致。

主从配置就是围绕这个原理配置，也就是说：从库会生成两个线程,一个I/O线程,一个SQL线程;I/O线程会去请求主库的binlog,并将得到的binlog写到本地的relay-log(中继日志)文件中;主库会生成一个log dump线程,用来给从库I/O线程传binlog;SQL线程,会读取relay log文件中的日志,并解析成sql语句逐一执行;

有一点需要注意的是，就是从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。

由于从库从主库拷贝日志以及串行执行 SQL 的特点，在高并发场景下，从库的数据是有延时的。

在实际运用中，时常会出现这样的情况，主库的数据已经有了，可从库还是读取不到，可能要过几十毫秒，甚至几百毫秒才能读取到。

另外可能还需要注意另一个问题，就是如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就丢失了。

所以 MySQL实际上在这一块有两个机制：

一个是半同步复制，用来解决主库数据丢失问题；
一个是并行复制，用来解决从库复制延迟的问题。

半同步复制，也叫 semi-sync 复制，指的就是主库写入 binlog 日志之后，就会将强制此时立即将数据同步到从库，从库将日志写入自己本地的 relay log 之后，接着会返回一个 ack 给主库，主库接收到至少一个从库的 ack 之后才会认为写操作完成了。

并行复制，指的是从库开启多个线程，并行读取 relay log 中不同库的日志，然后并行重放不同库的日志，这是库级别的并行。

3、MySQL 主从同步延时问题

譬如用户升级条件达到了，主库也成功更新了用户状态，可在生产环境高峰期，这个时候，主从复制延时了，从库在高峰期时候却没更新。导致用户在手机app界面上显示的等级还是原来的。

主从延时排查方法

MySQL 有主从同步的状态信息，可以通过MySQL命令 show slave status获取，除了获知当前是否主从同步正常工作，另外一个重要指标就是 Seconds_Behind_Master，根据输出的Seconds_Behind_Master参数的值来判断：NULL，表示io_thread或是sql_thread有任何一个发生故障；0，该值为零，表示主从复制良好；正值，表示主从已经出现延时，数字越大表示从库延迟越严重。

4、主从延迟解决方案

一般来说，如果主从延迟较为严重，有以下解决方案：