【MySQL45讲】主备延迟导致读写分离的问题

一主多从架构应用场景的读写分离时，应该怎么处理主备延迟导致的读写分离问题呢？

一、读写分离的架构

读写分离的主要目标是分摊主库的压力，接下来看看两种读写分离的架构

1.1 客户端直连

上图中的结构是客户端(client)主动做负载均衡，这种模式下一般会把数据库的连接信息放在客户端的连接层，也就是说，由客户端来选择后端数据库进行查询

1.2 proxy代理

还有一种架构是，在MySQL和客户端之间有一个中间代理层proxy，客户端只连接proxy， 由 proxy根据请求类型和上下文决定请求的分发路由

1.3 客户端直连 vs proxy代理

接下来，看一下客户端直连和带proxy的读写分离架构，各有哪些特点

1. 客户端直连方案
   因为少了一层proxy转发，所以查询性能稍微好一点儿，并且整体架构简单，排查问题更方便
   但是这种方案，由于要了解后端部署细节，所以在出现主备切换、 库迁移等操作的时候，客户端都会感知到，并且需要调整数据库连接信息
   可能会觉得这样客户端也太麻烦了，信息大量冗余，架构很丑，其实也未必，一般采用这样的架构，一定会伴随一个负责管理后端的组件，比如Zookeeper，尽量让业务端只专注于业务逻辑开发

2. proxy代理方案
   对客户端比较友好
   客户端不需要关注后端细节，连接维护、后端信息维护等工作，都是由proxy完成的
   但这样的话，对后端维护团队的要求会更高，而且，proxy也需要有高可用架构
   因此，带proxy架构的整体就相对比较复杂

理解了这两种方案的优劣，具体选择哪个方案就取决于数据库团队提供的能力了
但目前看，趋势是往带proxy的架构方向发展

二、过期读

但是，不论使用哪种架构，都会碰到今天要讨论的问题：由于主从可能存在延迟

• 何谓主从延迟

客户端执行完一个更新事务后马上发起查询，如果查询选择的是从库的话，就有可能读到刚刚的事务更新之前的状态

• 何谓过期读

这种在从库上会读到系统的一个过期状态的现象，也可以暂且称之为"过期读"

前面说过了几种可能导致主备延迟的原因，以及对应的优化策略，但是主从延迟还是不能100%避免的
不论哪种结构，客户端都希望查询从库的数据结果，跟查主库的数据结果是一样的

• 处理过期读的方案

1. 强制走主库方案
2. sleep方案
3. 判断主备无延迟方案
4. 配合semi-sync方案
5. 等主库位点方案
6. 等GTID方案

三、强制走主库方案

强制走主库方案其实就是，将查询请求做分类

通常情况下，可以将查询请求分为两类：

1. 必须要拿到最新结果的请求，强制将其发到主库上
   比如，在一个交易平台上，卖家发布商品以后，马上要返回主页面，看商品是否发布成功，那么这个请求需要拿到最新的结果，就必须走主库
2. 对于可以读到旧数据的请求，将其发到从库上
   在这个交易平台上，买家来逛商铺页面，就算晚几秒看到最新发布的商品，也是可以接受的，那么这类请求就可以走从库

这个方案是不是有点畏难和取巧的意思呢，但其实这个方案是用得最多的

当然，这个方案最大的问题在于，有时候会碰到"所有查询都不能是过期读"的需求，比如一些金融类的业务。这样的话，就要放弃读写分离，所有读写压力都在主库，等同于放弃了扩展性

因此接下来，讨论的话题是：可以支持读写分离的场景下，有哪些解决过期读的方案，并分析各个方案的优缺点

四、Sleep 方案

主库更新后，读从库之前先sleep一下。具体的方案就是，类似于执行一条select sleep(1)命令

这个方案的假设是，大多数情况下主备延迟在1秒之内，做一个sleep可以有很大概率拿到最新 的数据

这个方案的第一感觉，很可能是不靠谱儿，应该不会有人用吧？并且，直接在发起查询时先执行一条sleep语句，用户体验很不友好

但，这个思路确实可以在一定程度上解决问题，为了看起来更靠谱儿，可以换一种方式

以卖家发布商品为例，商品发布后，用Ajax(Asynchronous JavaScript + XML，异步JavaScript和XML)直接把客户端输入的内容作为"新的商品"显示在页面上，而不是真正地去数据库做查询

这样，卖家就可以通过这个显示，来确认产品已经发布成功了，等到卖家再刷新页面去查看商品的时候，其实已经过了一段时间，也就达到了sleep的目的，进而也就解决了过期读的问题

也就是说，这个sleep方案确实解决了类似场景下的过期读问题。但，从严格意义上来说，这个方案存在的问题就是不精确，这个不精确包含了两层意思：

1. 如果这个查询请求本来0.5秒就可以在从库上拿到正确结果，也会等1秒
2. 如果延迟超过1秒，还是会出现过期读

看到这里，是不是有一种你是不是在逗我的感觉，这个改进方案虽然可以解决类似Ajax场景下的过期读问题，但还是怎么看都不靠谱儿
别着急，接下来介绍一些更准确的方案

五、判断主备无延迟方案

要确保备库无延迟，通常有三种做法

5.1 seconds_behind_master

第一种确保主备无延迟的方法是：每次从库执行查询请求前，先判断 seconds_behind_master是否已经等于0
如果还不等于0 ，那就必须等到这个参数变为0才能执行查询请求

执行show slave status结果中的seconds_behind_master参数的值，可以用来衡量主备延迟时间的长短

seconds_behind_master的单位是秒，如果觉得精度不够的话，还可以采用对比位点和GTID的方法来确保主备无延迟，也就是接下来要说的第二和第三种方法

show slave status结果的部分截图如下图所示：

现在可以通过这个结果，看看具体如何通过对比位点和GTID来确保主备无延迟

5.2 对比位点

第二种确保主备无延迟的方法是：对比位点确保主备无延迟

• Master_Log_File和Read_Master_Log_Pos

表示的是读到的主库的最新位点

• Relay_Master_Log_File和Exec_Master_Log_Pos

表示的是备库执行的最新位点

如果下面这两组数据
Master_Log_File和Relay_Master_Log_File
Read_Master_Log_Pos和 Exec_Master_Log_Pos
的值完全相同，就表示接收到的日志已经同步完成

5.3 对比GTID集合

第三种确保主备无延迟的方法是：对比GTID集合确保主备无延迟

• Auto_Position=1

表示这对主备关系使用了GTID协议

• Retrieved_Gtid_Set

备库收到的所有日志的GTID集合

• Executed_Gtid_Set

备库所有已经执行完成的GTID集合

如果两个GTID集合相同，表示备库接收到的日志都已经同步完成

可见，对比位点和对比GTID这两种方法，都要比判断seconds_behind_master是否为0更准确

六、配合semi-sync

在执行查询请求之前，先判断从库是否同步完成的方法，相比于sleep方案，准确度确实提升了不少，但还是没有达到完全精确的程度

那为什么这么说呢？

6.1 主库和备库信息不对等

现在一起来回顾下，一个事务的binlog在主备库之间的状态：

1. 主库执行完成，写入binlog，并反馈给客户端
2. binlog被从主库发送给备库，备库收到
3. 在备库执行binlog完成

上面判断主备无延迟的逻辑，是备库收到的日志都执行完成。但是，从binlog在主备之间状态的分析中，不难看出还有一部分日志，处于客户端已经收到提交确认，而备库还没收到日志的状态

如下图所示就是这样的一种状态，很明显备库还没收到trx3

这时，主库上执行完成了三个事务trx1、trx2和trx3，其中：

1. trx1和trx2已经传到从库，并且已经执行完成了
2. trx3在主库执行完成，并且已经回复给客户端，但是还没有传到从库中

如果这时候在从库B上执行查询请求，按照上面的逻辑，从库认为已经没有同步延迟，但还是查不到trx3的，严格地说，就是出现了过期读

那么，这个问题有没有办法解决呢？

要解决这个问题，就要引入半同步复制，也就是semi-sync replication

6.2 semi-sync的设计

semi-sync的设计如下：

1. 事务提交的时候，主库把binlog发给从库
2. 从库收到binlog以后，发回给主库一个ack，表示收到
3. 主库收到这个ack以后，才能给客户端返回"事务完成"的确认

也就是说，如果启用了semi-sync，就表示所有给客户端发送过确认的事务，都确保了备库已 经收到了这个日志

如果主库掉电的时候，有些binlog还来不及发给从库，会不会导致系统数据丢失？
答案是：如果使用的是普通的异步复制模式，就可能会丢失，但semi-sync就可以解决这个问 题

这样，semi-sync配合前面关于位点的判断，就能够确定在从库上执行的查询请求，可以避免 过期读

6.3 一主多从的问题

semi-sync+位点判断的方案，只对一主一备的场景是成立的

在一主多从场景中，主库只要等到一个从库的ack，就开始给客户端返回确认

在从库上执行查询请求，就有两种情况：

1. 如果查询是落在这个响应了ack的从库上，是能够确保读到最新数据
2. 如果是查询落到其他从库上，它们可能还没有收到最新的日志，就会产生过期读的问题

6.4 同步位点无法响应的问题

其实，判断同步位点的方案还有另外一个潜在的问题，即：
如果在业务更新的高峰期，主库的位点或者GTID集合更新很快，那么上面的两个位点等值判断就会一直不成立，很可能出现从库上迟迟无法响应查询请求的情况

实际上，回到最初的业务逻辑里，当发起一个查询请求以后，要得到准确的结果， 其实并不需要等到主备完全同步

为什么这么说呢？我们来看一下这个时序图

如上图所示，就是等待位点方案的一个bad case
图中备库B下的虚线框，分别表示relaylog和binlog中的事务，可以看到，图中从状态1到状态4，一直处于延迟一个事务的状态

备库B一直到状态4都和主库A存在延迟，如果用上面必须等到无延迟才能查询的方案，select 语句直到状态4都不能被执行

但是，其实客户端是在发完trx1更新后发起的select语句，只需要确保trx1已经执行完成就可以执行select语句，也就是说，如果在状态3执行查询请求，得到的就是预期结果

6.4 semi-sync存在的问题

到这里小结一下，semi-sync配合判断主备无延迟的方案，存在两个问题：

1. 一主多从的时候，在某些从库执行查询请求会存在过期读的现象
2. 在持续延迟的情况下，可能出现过度等待的问题

接下来，介绍的等主库位点方案，可以解决这两个问题

七、等主库位点方案

7.1 master_pos_wait执行逻辑

要理解等主库位点方案，需要先介绍一条命令：

select master_pos_wait(file, pos[, timeout]);

1. 它是在从库执行的
2. 参数file和pos指的是主库上的文件名和位置
3. timeout可选，设置为正整数N表示这个函数最多等待N秒

这个命令正常返回的结果是一个正整数M，表示从命令开始执行，到应用完file和pos表示的 binlog位置，执行了多少事务

当然，除了正常返回一个正整数M外，这条命令还会返回一些其他结果，包括：

1. 如果执行期间，备库同步线程发生异常，则返回NULL
2. 如果等待超过N秒，就返回-1
3. 如果刚开始执行的时候，就发现已经执行过这个位置了，则返回0

7.2 master_pos_wait执行流程

对于上面执行时序图中先执行trx1，再执行一个查询请求的逻辑，要保证能够查到正确的数据，可以使用这个逻辑

1. trx1事务更新完成后，马上执行show master status得到当前主库执行到的File和Position
2. 选定一个从库执行查询语句
3. 在从库上执行select master_pos_wait(File, Position, 1)
4. 如果返回值是>=0的正整数，则在这个从库执行查询语句
5. 否则，到主库执行查询语句

把上面这个 master_pos_wait方案的流程画出来如下：

假设这条select查询最多在从库上等待1秒。那么，如果1秒内master_pos_wait返回一个大于等于0的整数，就确保了从库上执行的这个查询结果一定包含了trx1的数据

7.3 超时处理

步骤5到主库执行查询语句，是这类方案常用的退化机制。因为从库的延迟时间不可控，不能 无限等待，所以如果等待超时，就应该放弃，然后到主库去查

那如果所有的从库都延迟超过1秒了，那查询压力不就都跑到主库上了吗？确实是这样

但是，按照设定不允许过期读的要求，就只有两种选择

1. 超时放弃
2. 转到主库查询

具体怎么选择，就需要在业务开发时做好限流策略

八、GTID方案

如果数据库开启了GTID模式，对应的也有等待GTID的方案

8.1 wait_for_executed_gtid_set执行逻辑

MySQL中同样提供了一个类似的命令：

select wait_for_executed_gtid_set(gtid_set, 1);

这条命令的逻辑是：

1. 等待，直到这个库执行的事务中包含传入的gtid_set，返回0
2. 超时返回1

在前面等位点的方案中，执行完事务后还要主动去主库执行show master status，而 MySQL
5.7.6版本开始，允许在执行完更新类事务后，把这个事务的GTID返回给客户端，这样等GTID的方案就可以减少一次查询

8.2 等GTID的执行流程

等GTID的执行流程如下：

1. trx1事务更新完成后，从返回包直接获取这个事务的GTID，记为gtid1
2. 选定一个从库执行查询语句
3. 在从库上执行 select wait_for_executed_gtid_set(gtid1, 1)
4. 如果返回值是0，则在这个从库执行查询语句
5. 否则，到主库执行查询语句

跟等主库位点的方案一样，等待超时后是否直接到主库查询，需要业务开发业务时做限流考虑

wait_for_executed_gtid_set方案流程图如下：

在上图所示的第一步中，trx1事务更新完成后，从返回包直接获取这个事务的GTID。问题是，怎么 能够让MySQL在执行事务后，返回包中带上GTID呢？

将参数session_track_gtids设置为OWN_GTID，再通过API接口mysql_session_track_get_first从返回包解析出GTID的值即可

九、小结

介绍一主多从做读写分离时，可能碰到过期读的原因，以及几种应对的方案

这几种方案中，有的方案看上去是做了妥协，有的方案看上去不那么靠谱儿，但都是有实际应用场景的，需要根据业务需求选择

即使是最后等待位点和等待GTID这两个方案，虽然看上去比较靠谱，但仍然存在需要权衡的情况，如果所有的从库都延迟，那么请求就会全部落到主库上，这时候会不会由于压力突然增大，把主库打挂了呢？

其实，在实际应用中，这几个方案是可以混合使用的
比如：

1. 先在客户端对请求做分类，区分哪些请求可以接受过期读，而哪些请求完全不能接受过期
2. 然后对于不能接受过期读的语句，再使用等GTID或等位点的方案

但话说回来，过期读在本质上是由一写多读导致的
在实际应用中，可能会有别的不需要等待就可以水平扩展的数据库方案，但这往往是用牺牲写性能换来的，也就是需要在读性能和写性能中取权衡