MySQL之读写分离

骑猪看日落 2021-08-30 23:56 410阅读 0赞

### MySQL之读写分离 ###

*  1. 前言
 *  2. 复制的工作原理
 *  3. 主从不一致原因
 *  4. 主从不一致解决方案

# 1. 前言 #

[Redis 主从复制][Redis]

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

# 2. 复制的工作原理 #

复制分为以下`3`个步骤：

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

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70]  
       主服务器有一个线程负责发送二进制日志。

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

# 3. 主从不一致原因 #

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

# 4. 主从不一致解决方案 #

1.  半同步复制

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

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

1.  并行复制

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

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

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

1.  分库

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

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

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

1.  修改代码逻辑

[主从不一致解决方案][Link 1]

[Redis]: https://blog.csdn.net/wang_zhao_/article/details/106736897
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70]: /images/20210813/f4f0109c44e5422b970cf766ee50a5f1.png
[Link 1]: https://segmentfault.com/a/1190000010134025