(
1
)如何实现
mysql
的读写分离？
其实很简单，就是基于主从复制架构，简单来说，就搞一个主库，挂多个从库，然后我们就单单只是写主库，然后主库会自动把数据给同步到从库上去。
(
2
)
MySQL
主从复制原理的是啥？
主库将变更写
binlog
日志，然后从库连接到主库之后，从库有一个
IO
线程，将主库的
binlog
日志拷贝到自己本地，写入一个中继日志中。接着从库中有一个
SQL
线程会从中继日志读取
binlog
，然后执行
binlog
日志中的内容，也就是在自己本地再次执行一遍
SQL
，这样就可以保证自己跟主库的数据是一样的。
这里有一个非常重要的一点，就是从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行
SQL
的特点，在高并发场景下，从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。
而且这里还有另外一个问题，就是如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就丢失了。
所以
mysql
实际上在这一块有两个机制，一个是半同步复制，用来解决主库数据丢失问题；一个是并行复制，用来解决主从同步延时问题。
这个所谓半同步复制，
semi-sync
复制，指的就是主库写入
binlog
日志之后，就会将强制此时立即将数据同步到从库，从库将日志写入自己本地的
relay log
之后，接着会返回一个
ack
给主库，主库接收到至少一个从库的
ack
之后才会认为写操作完成了。
所谓并行复制，指的是从库开启多个线程，并行读取
relay log
中不同库的日志，然后并行重放不同库的日志，这是库级别的并行。
-
主从复制的原理
-
主从延迟问题产生的原因
-
主从复制的数据丢失问题，以及半同步复制的原理
-
并行复制的原理，多库并发重放
relay
日志，缓解主从延迟问题
(
3
)
mysql
主从同步延时问题(精华)
线上确实处理过因为主从同步延时问题，导致的线上的
bug
，小型的生产事故
show status
，
Seconds_Behind_Master
，你可以看到从库复制主库的数据落后了几
ms
其实这块东西我们经常会碰到，就比如说用了
mysql
主从架构之后，可能会发现，刚写入库的数据结果没查到，结果就完蛋了。。。。
所以实际上你要考虑好应该在什么场景下来用这个
mysql
主从同步，建议是一般在读远远多于写，而且读的时候一般对数据时效性要求没那么高的时候，用
mysql
主从同步
所以这个时候，我们可以考虑的一个事情就是，你可以用
mysql
的并行复制，但是问题是那是库级别的并行，所以有时候作用不是很大
所以这个时候。。通常来说，我们会对于那种写了之后立马就要保证可以查到的场景，采用强制读主库的方式，这样就可以保证你肯定的可以读到数据了吧。其实用一些数据库中间件是没问题的。
一般来说，如果主从延迟较为严重
-
分库，将一个主库拆分为
4
个主库，每个主库的写并发就
500/s
，此时主从延迟可以忽略不计
-
打开
mysql
支持的并行复制，多个库并行复制，如果说某个库的写入并发就是特别高，单库写并发达到了
2000/s
，并行复制还是没意义。
28
法则，很多时候比如说，就是少数的几个订单表，写入了
2000/s
，其他几十个表
10/s
。
-
重写代码，写代码的同学，要慎重，当时我们其实短期是让那个同学重写了一下代码，插入数据之后，直接就更新，不要查询
-
如果确实是存在必