MySQL深入25-读写分离的过期读问题
# MySQL深入25-读写分离的过期读问题
一主多从的结构：
读写分离的主要目标就是分摊主库的压力。客户端（client）主动做负载均衡，这种模式下一般会把数据库的连接信息放在客户端的连接层。相当于客户端来选择后端数据进行查询。
另一种架构是，在MySQL和客户端之间有一个中间代理层proxy，客户端只连接proxy，由proxy 根据请求类型和上下文决定请求的分发路由。
客户端直连和带proxy的读写分离架构各自特点如下：
- 客户端直连方案，因为少了一层 proxy 转发，所以查询性能稍微好一点儿，并且整体架构简单，排查问题更方便。但是这种方案，由于要了解后端部署细节，所以在出现主备切换、库迁移等操作的时候，客户端都会感知到，并且需要调整数据库连接信息。
- 带 proxy 的架构，对客户端比较友好。客户端不需要关注后端细节，连接维护、后端信息维护等工作，都是由 proxy 完成的。但这样的话，对后端维护团队的要求会更高。而且，proxy 也需要有高可用架构。因此，带 proxy 架构的整体就相对比较复杂。
但是无论使用那种架构，都会存在一个问题：由于主从可能存在延迟，客户端执行完一个更新事务之后马上发起查询，如果查询的选择的是从库的话，就可能读到更新之前的状态。
这种“在从库上会读到系统的一个过期状态”的现象，在这篇文章里，我们暂且称之为“过期读”。
解决“过期读”的方案主要包括：强制走主库方案、sleep方案、判断主备无延迟方案、配合 semi-sync 方案、等主库位点方案、等 GTID 方案。
# 强制走主库方案
强制走主库的方案其实就是对我们的查询进行分类：
- 对于必须要拿到最新结果的请求，强制将其发到主库上。
- 对于可以拿到旧结果的请求，才将其发到从库上。
该方案是用得最多的，但是对于某一些业务所有查询都不能是过期读，该方案就必须要放弃读写分离，让所有读写压力都在主库，等同于放弃扩展性。
下面介绍一些在可以支持读写分离的场景下，解决过期读的方案。
# Sleep方案
主库更新后，读从库之前先sleep一下。具体的方案就是，类似于执行一条 select sleep(1) 命令。
这个方案的假设是，大多数情况下主备延迟在 1 秒之内，做一个 sleep 可以有很大概率拿到最新的数据。
有些场景会运用上面的思想，比如用户修改自己状态后，我们把新状态直接显示在页面，而不是真正地去数据库做查询，等下一次用户刷新页面的时候，把真正数据拿出来。其实这种方案就达到了sleep的目的，进而也解决了过期读的问题。
也就是说，这个 sleep 方案确实解决了类似场景下的过期读问题。但，从严格意义上来说，这个方案存在的问题就是不精确。这个不精确包含了两层意思：
如果这个查询请求本来 0.5 秒就可以在从库上拿到正确结果，也会等 1 秒；
如果延迟超过 1 秒，还是会出现过期读。
# 判断主备无延迟方案
方法一：判断seconds_behind_master
每次从库执行查询请求前，先判断 seconds_behind_master 是否已经等于 0。如果还不等于 0 ，那就必须等到这个参数变为 0 才能执行查询请求。
seconds_behind_master的单位是秒，可能存在精度不够的情况。
方法二：对比位点确保主备无延迟
- 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 这两组值完全相同，就表示接收到的日志已经同步完成。
方法三：对比GTID集合确保主备无延迟
- Auto_Position=1 ，表示这对主备关系使用了 GTID 协议。
- Retrieved_Gtid_Set，是备库收到的所有日志的 GTID 集合；
- Executed_Gtid_Set，是备库所有已经执行完成的 GTID 集合。
如果这两个集合相同，也就是表示备库接收到的日志已经同步完成。
方法三和方法二相比方法一更加精确，同时该方案相比sleep方案，精确度确实也提升不少，但是仍然存在不精确。
一个事务的binlog在主备库的状态：
- 主库执行完成，写入 binlog，并反馈给客户端；
- binlog 被从主库发送给备库，备库收到；
- 在备库执行 binlog 完成。
之前判断主备无延迟的逻辑是：备库把收到的日志全部执行完成了，但是在有一部分日志是处于客户端已经收到提交确认，而备库还没收到日志的状态。
对于上图而言，主库上执行完成了三个事务trx1、trx2 和 trx3，其中：
- trx1 和 trx2 已经传到从库，并且已经执行完成了；
- trx3 在主库执行完成，并且已经回复给客户端，但是还没有传到从库中。
如果这时候在从库B上执行查询请求，按照上文逻辑，从库认为已经没有同步延迟，但是查不到trx3，也就是说还是出现了过期读。
# 配合semi-sync
要解决上述问题，就需要引入半同步复制，也就是semi-sync replication。
semi-sync设计如下：
- 事务提交的时候，主库把 binlog 发给从库；
- 从库收到 binlog 以后，发回给主库一个 ack，表示收到了；
- 主库收到这个 ack 以后，才能给客户端返回“事务完成”的确认。
通过这种方式所有给客户端发送过确认的事务，就是备库已经确认收到了这个日志。但是semi-sync+位点判断的方案，只对一主一备的场景是成立的。在一主多从场景中，主库只要等到一个从库的ack，就开始给客户端返回确认。这时，在从库上执行查询请求，就存在两种情况：
- 如果查询是落在这个响应了 ack 的从库上，是能够确保读到最新数据；
- 但如果是查询落到其他从库上，它们可能还没有收到最新的日志，就会产生过期读的问题。
另外，在我们最初的业务逻辑里，当发起一个查询请求以后，我们要得到精确的结果，其实不并需要等到“主备完全同步”。
上图中，从状态1到状态4，一直处于延迟一个事务的状态。备库 B 一直到状态 4 都和主库 A 存在延迟，如果用上面必须等到无延迟才能查询的方案，select 语句直到状态 4 都不能被执行。但是，其实客户端是在发完 trx1 更新后发起的 select 语句，我们只需要确保 trx1 已经执行完成就可以执行 select 语句了。也就是说，如果在状态 3 执行查询请求，得到的就是预期结果了。
总结一下，该方案存在两个问题：
- 一主多从的时候，在某些从库执行查询请求会存在过期读的现象；
- 在持续延迟的情况下，可能出现过度等待的问题。
# 等主库位点方案
select master_pos_wait(file, pos[, timeout]);
命令的逻辑如下：
- 它是在从库执行的；
- 参数 file 和 pos 指的是主库上的文件名和位置；
- timeout 可选，设置为正整数 N 表示这个函数最多等待 N 秒。
这条命令正常返回的结果是一个正整数M：表示从命令开始执行，到应用完file和pos表示的binlog位置，执行了多少事务。
对于上诉案例中，先执行trx1，再执行一个查询请求的逻辑，要保证能够查到正确的数据，我们的逻辑如下：
- trx1 事务更新完成后，马上执行 show master status 得到当前主库执行到的 File 和 Position；
- 选定一个从库执行查询语句；
- 在从库上执行 select master_pos_wait(File, Position, 1)；
- 如果返回值是 >=0 的正整数，则在这个从库执行查询语句；
- 否则，到主库执行查询语句。
# GTID方案
如果数据库开启了GTID模式，对应的也有等待GTID的方案。
select wait_for_executed_gtid_set(gtid_set, 1);
这条命令逻辑如下：
- 等待，直到这个库执行的事务中包含传入的 gtid_set，返回 0；
- 超时返回 1。
在前面等位点的方案中，我们执行完事务后，还要主动去主库执行show master status。而等GTID方案允许在执行完更新类事务后，把这个事务的GTID返回给客户端，这样等GTID的方案就可以减少一次查询。
- trx1 事务更新完成后，从返回包直接获取这个事务的 GTID，记为 gtid1；
- 选定一个从库执行查询语句；
- 在从库上执行 select wait_for_executed_gtid_set(gtid1, 1)；
- 如果返回值是 0，则在这个从库执行查询语句；
- 否则，到主库执行查询语句。
