MySQL之读写分离

1. 前言

       Redis 主从复制

       MySQL读写分离的作用同Redis主从复制一样，写请求由Master负责，读请求由Slave负责。从而实现读写在不同实例完成，提高读写的并发量。

2. 复制的工作原理

       复制分为以下3个步骤：

1. master把数据更改记录到二进制日志(binlog)中。
2. slave把主服务器的二进制日志复制到自己的中继日志(relay log)中。
3. 从服务器重做中继日志中的日志，把更改应用到自己的数据库上，以达到数据的一致性。

       复制并不是实时地进行同步，而是异步实时。这样就有可能在数据被写入到master后，还没有同步到slave，在这期间便造成了主从不一致。

       主服务器有一个线程负责发送二进制日志。

       从服务器有 2 个线程，一个是I/O线程，负责读取主服务器地二进制日志，并将其保存为中继日志；另一个是SQL线程，负责执行中继日志。

3. 主从不一致原因

1. 从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行SQL的特点，在高并发场景下，从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。
2. 还有另外一个问题，就是如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就丢失了。

4. 主从不一致解决方案

1. 半同步复制

       半同步复制，用来解决主库数据丢失问题。

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

2. 并行复制

       并行复制，用来解决主从同步延时问题。

       并行复制，指的是从库开启多个线程，并行读取relay log中不同库的日志，然后并行重写不同库的日志，这是库级别的并行。但这是库级别的并行，所以有时候作用不是很大。

       如果主从延迟较为严重，可以采用以下方案：

1. 分库

       不进行读写分离，将一个主库拆分成多个主库，这样便可以提高并发量和吞吐量。在Redis分布式锁的实现中，正是由于主从数据可能不一致，我们选择多个Master，而没有使用读写分离的方案。

2. 如果确实是存在必须先插入，立马要求就查询到，然后立马就要反过来执行一些操作，对这个查询设置直连主库。

       这样造成的效果便是我们原本采用读写分离的方案，但此时没有进行分离。

3. 修改代码逻辑

       主从不一致解决方案