数据库：读写分离 — 问题汇总

问题：

• 如何实现 MySQL 的读写分离？
• MySQL 主从复制原理是啥？
• 如何解决 MySQL 主从同步的延时问题？

分析

　　高并发这个阶段，确定是须要作读写分离的，啥意思？由于实际上大部分的互联网公司，一些网站，或者是 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 status

　查看 Seconds_Behind_Master，能够看到从库复制主库的数据落后了几 ms。

　通常来讲，若是主从延迟较为严重，有如下解决方案：

• 分库，将一个主库拆分为多个主库，每一个主库的写并发就减小了几倍，此时主从延迟能够忽略不计。
• 打开 MySQL 支持的并行复制，多个库并行复制。若是说某个库的写入并发就是特别高，单库写并发达到了 2000/s，并行复制仍是没意义。
• 重写代码，写代码的同窗，要慎重，插入数据时立马查询可能查不到。
• 若是确实是存在必须先插入，立马要求就查询到，而后立马就要反过来执行一些操做，对这个查询设置直连主库。不推荐这种方法，你要是这么搞，读写分离的意义就丧失了。

 

出处：https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/mysql-read-write-separation.md