共计 1412 个字符，预计需要花费 4 分钟才能阅读完成。
前言
高并发这个阶段，必定是须要做读写拆散的，啥意思？因为实际上大部分的互联网公司，一些网站，或者是 app，其实都是读多写少。所以针对这个状况，就是写一个主库，然而主库挂多个从库，而后从多个从库来读，那不就能够撑持更高的读并发压力了吗？那具体什么是读写拆散又如何解决其中的提早问题呢？赶快一起来看看吧！
如何实现 MySQL 的读写拆散？
其实很简略，就是基于主从复制架构，简略来说，就搞一个主库，挂多个从库，而后咱们就单单只是写主库，而后主库会主动把数据给同步到从库下来。
MySQL 主从复制原理的是啥？
主库将变更写入 binlog 日志，而后从库连贯到主库之后，从库有一个 IO 线程，将主库的 binlog 日志拷贝到本人本地，写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog，而后执行 binlog 日志中的内容，也就是在本人本地再次执行一遍 SQL，这样就能够保障本人跟主库的数据是一样的。
这里有一个十分重要的一点，就是从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。所以这就是一个十分重要的点了，因为从库从主库拷贝日志以及串行执行 SQL 的特点，在高并发场景下，从库的数据肯定会比主库慢一些，是 有延时 的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒能力读取到。
而且这里还有另外一个问题，就是如果主库忽然宕机，而后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就失落了。
所以 MySQL 实际上在这一块有两个机制，一个是 半同步复制 ，用来解决主库数据失落问题；一个是 并行复制，用来解决主从同步延时问题。
这个所谓 半同步复制 ，也叫 semi-sync 复制，指的就是主库写入 binlog 日志之后，就会将 强制 此时立刻将数据同步到从库，从库将日志写入本人本地的 relay log 之后，接着会返回一个 ack 给主库，主库接管到 至多一个从库 的 ack 之后才会认为写操作实现了。
所谓 并行复制 ，指的是从库开启多个线程，并行读取 relay log 中不同库的日志，而后 并行重放不同库的日志，这是库级别的并行。
MySQL 主从同步延时问题（精髓）
以火线上的确解决过因为主从同步延时问题而导致的线上的 bug，属于小型的生产事变。
是这个么场景。有个同学是这样写代码逻辑的。先插入一条数据，再把它查出来，而后更新这条数据。在生产环境高峰期，写并发达到了 2000/s，这个时候，主从复制延时大略是在小几十毫秒。线上会发现，每天总有那么一些数据，咱们冀望更新一些重要的数据状态，但在高峰期时候却没更新。用户跟客服反馈，而客服就会反馈给咱们。
咱们通过 MySQL 命令：
show slave status
复制代码查看 Seconds_Behind_Master，能够看到从库复制主库的数据落后了几 ms。
一般来说，如果主从提早较为重大，有以下解决方案：
- 分库，将一个主库拆分为多个主库，每个主库的写并发就缩小了几倍，此时主从提早能够忽略不计。
- 关上 MySQL 反对的并行复制，多个库并行复制。如果说某个库的写入并发就是特地高，单库写并发达到了 2000/s，并行复制还是没意义。
- 重写代码，写代码的同学，要谨慎，插入数据时立马查问可能查不到。
- 如果的确是存在必须先插入，立马要求就查问到，而后立马就要反过来执行一些操作，对这个查问 设置直连主库 。 不举荐 这种办法，你要是这么搞，读写拆散的意义就丢失了。
出处。
