MySQL实战45讲学习笔记：第二十八讲

 1、读写分离架构

在上一篇文章中，我和你介绍了一主多从的结构以及切换流程。今天咱们就继续聊聊一主多从架构的应用场景：读写分离，以及怎么处理主备延迟致使的读写分离问题。

咱们在上一篇文章中提到的一主多从的结构，其实就是读写分离的基本结构了。这里，我再把这张图贴过来，方便你理解。

一、读写分离基本结构

图 1 读写分离基本结构

读写分离的主要目标就是分摊主库的压力。图 1 中的结构是客户端（client）主动作负载均衡，这种模式下通常会把数据库的链接信息放在客户端的链接层。也就是说，由客户端
来选择后端数据库进行查询。

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

二、带 proxy 的读写分离架构

图 2 带 proxy 的读写分离架构

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

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

2. 带 proxy 的架构，对客户端比较友好。客户端不须要关注后端细节，链接维护、后端信息维护等工做，都是由 proxy 完成的。但这样的话，对后端维护团队的要求会更高。而
且，proxy 也须要有高可用架构。所以，带 proxy 架构的总体就相对比较复杂。理解了这两种方案的优劣，具体选择哪一个方案就取决于数据库团队提供的能力了。但目前看，趋势是往带 proxy 的架构方向发展的。

可是，不论使用哪一种架构，你都会碰到咱们今天要讨论的问题：因为主从可能存在延迟，客户端执行完一个更新事务后立刻发起查询，若是查询选择的是从库的话，就有可能读到
刚刚的事务更新以前的状态。

这种“在从库上会读到系统的一个过时状态”的现象，在这篇文章里，咱们暂且称之为“过时读”。

前面咱们说过了几种可能致使主备延迟的缘由，以及对应的优化策略，可是主从延迟仍是不能 100% 避免的。

不论哪一种结构，客户端都但愿查询从库的数据结果，跟查主库的数据结果是同样的。接下来，咱们就来讨论怎么处理过时读问题。

这里，我先把文章中涉及到的处理过时读的方案汇总在这里，以帮助你更好地理解和掌握全文的知识脉络。这些方案包括：

• 强制走主库方案；
• sleep 方案；
• 判断主备无延迟方案；
• 配合 semi-sync 方案；
• 等主库位点方案；
• 等 GTID 方案。

2、强制走主库方案

强制走主库方案其实就是，将查询请求作分类。一般状况下，咱们能够将查询请求分为这么两类：

1. 对于必需要拿到最新结果的请求，强制将其发到主库上。好比，在一个交易平台上，卖家发布商品之后，立刻要返回主页面，看商品是否发布成功。那么，这个请求须要拿到
最新的结果，就必须走主库。

2. 对于能够读到旧数据的请求，才将其发到从库上。在这个交易平台上，买家来逛商铺页面，就算晚几秒看到最新发布的商品，也是能够接受的。那么，这类请求就能够走从库。

你可能会说，这个方案是否是有点畏难和取巧的意思，但其实这个方案是用得最多的。

固然，这个方案最大的问题在于，有时候你会碰到“全部查询都不能是过时读”的需求，

好比一些金融类的业务。这样的话，你就要放弃读写分离，全部读写压力都在主库，等同于放弃了扩展性。

所以接下来，咱们来讨论的话题是：能够支持读写分离的场景下，有哪些解决过时读的方案，并分析各个方案的优缺点。

3、Sleep 方案

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

这个方案的假设是，大多数状况下主备延迟在 1 秒以内，作一个 sleep 能够有很大几率拿到最新的数据。

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

但，这个思路确实能够在必定程度上解决问题。为了看起来更靠谱儿，咱们能够换一种方式。

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

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

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

1. 若是这个查询请求原本 0.5 秒就能够在从库上拿到正确结果，也会等 1 秒；
2. 若是延迟超过 1 秒，仍是会出现过时读。

看到这里，你是否是有一种“你是否是在逗我”的感受，这个改进方案虽然能够解决相似Ajax 场景下的过时读问题，但仍是怎么看都不靠谱儿。别着急，接下来我就和你介绍一些
更准确的方案。

4、判断主备无延迟方案

要确保备库无延迟，一般有三种作法。

经过前面的第 25 篇文章，咱们知道 show slave status 结果里的seconds_behind_master 参数的值，能够用来衡量主备延迟时间的长短。

一、第一种确保主备无延迟的方法是，每次从库执行查询请求前，先判断

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

seconds_behind_master 的单位是秒，若是你以为精度不够的话，还能够采用对比位点和 GTID 的方法来确保主备无延迟，也就是咱们接下来要说的第二和第三种方法。

如图 3 所示，是一个 show slave status 结果的部分截图。

图 3 show slave status 结果

如今，咱们就经过这个结果，来看看具体如何经过对比位点和 GTID 来确保主备无延迟。

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

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

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 集合。

若是这两个集合相同，也表示备库接收到的日志都已经同步完成。

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

在执行查询请求以前，先判断从库是否同步完成的方法，相比于 sleep 方案，准确度确实提高了很多，但仍是没有达到“精确”的程度。为何这么说呢？

咱们如今一块儿来回顾下，一个事务的 binlog 在主备库之间的状态：

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

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

如图 4 所示就是这样的一个状态。

图 4 备库还没收到 trx3这时，主库上执行完成了三个事务 trx一、trx2 和 trx3，其中：

1. trx1 和 trx2 已经传到从库，而且已经执行完成了；
2. trx3 在主库执行完成，而且已经回复给客户端，可是尚未传到从库中。

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

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

5、配合 semi-sync

要解决这个问题，就要引入半同步复制，也就是 semi-sync replication。semi-sync 作了这样的设计：

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

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

在第 25 篇文章的评论区，有同窗问到：若是主库掉电的时候，有些 binlog 还来不及发给从库，会不会致使系统数据丢失？

答案是，若是使用的是普通的异步复制模式，就可能会丢失，但 semi-sync 就能够解决这个问题。

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

可是，semi-sync+ 位点判断的方案，只对一主一备的场景是成立的。在一主多从场景中，主库只要等到一个从库的 ack，就开始给客户端返回确认。这时，在从库上执行查询
请求，就有两种状况：

1. 若是查询是落在这个响应了 ack 的从库上，是可以确保读到最新数据；
2. 但若是是查询落到其余从库上，它们可能尚未收到最新的日志，就会产生过时读的问题。

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

实际上，回到咱们最初的业务逻辑里，当发起一个查询请求之后，咱们要获得准确的结果，其实并不须要等到“主备彻底同步”。

为何这么说呢？咱们来看一下这个时序图。

 

图 5 主备持续延迟一个事务

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

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

可是，其实客户端是在发完 trx1 更新后发起的 select 语句，咱们只须要确保 trx1 已经执行完成就能够执行 select 语句了。也就是说，若是在状态 3 执行查询请求，获得的就是预
期结果了。

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

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

接下来，我要和你介绍的等主库位点方案，就能够解决这两个问题。

6、等主库位点方案

要理解等主库位点方案，我须要先和你介绍一条命令：

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。

对于图 5 中先执行 trx1，再执行一个查询请求的逻辑，要保证可以查到正确的数据，咱们可使用这个逻辑：

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

我把上面这个流程画出来。

图 6 master_pos_wait 方案

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

步骤 5 到主库执行查询语句，是这类方案经常使用的退化机制。由于从库的延迟时间不可控，不能无限等待，因此若是等待超时，就应该放弃，而后到主库去查。

你可能会说，若是全部的从库都延迟超过 1 秒了，那查询压力不就都跑到主库上了吗？确实是这样。

可是，按照咱们设定不容许过时读的要求，就只有两种选择，一种是超时放弃，一种是转到主库查询。具体怎么选择，就须要业务开发同窗作好限流策略了。

7、GTID 方案

若是你的数据库开启了 GTID 模式，对应的也有等待 GTID 的方案。MySQL 中一样提供了一个相似的命令：

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

这条命令的逻辑是：

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

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

这时，等 GTID 的执行流程就变成了：

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

跟等主库位点的方案同样，等待超时后是否直接到主库查询，须要业务开发同窗来作限流考虑。

我把这个流程图画出来。

图 7 wait_for_executed_gtid_set 方案

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

你只须要将参数 session_track_gtids 设置为 OWN_GTID，而后经过 API 接口mysql_session_track_get_first 从返回包解析出 GTID 的值便可。

在专栏的第一篇文章中，我介绍 mysql_reset_connection 的时候，评论区有同窗留言问这类接口应该怎么使用。

这里我再回答一下。其实，MySQL 并无提供这类接口的 SQL 用法，是提供给程序的API(https://dev.mysql.com/doc/refman/5.7/en/c-api-functions.html)。

好比，为了让客户端在事务提交后，返回的 GITD 可以在客户端显示出来，我对 MySQL客户端代码作了点修改，以下所示：

图 8 显示更新事务的 GTID-- 代码

这样，就能够看到语句执行完成，显示出 GITD 的值。

图 9 显示更新事务的 GTID-- 效果

固然了，这只是一个例子。你要使用这个方案的时候，仍是应该在你的客户端代码中调用mysql_session_track_get_first 这个函数。

8、小结

在今天这篇文章中，我跟你介绍了一主多从作读写分离时，可能碰到过时读的缘由，以及几种应对的方案。

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

即便是最后等待位点和等待 GTID 这两个方案，虽然看上去比较靠谱儿，但仍然存在须要权衡的状况。若是全部的从库都延迟，那么请求就会所有落到主库上，这时候会不会因为
压力忽然增大，把主库打挂了呢？

其实，在实际应用中，这几个方案是能够混合使用的。

好比，先在客户端对请求作分类，区分哪些请求能够接受过时读，而哪些请求彻底不能接受过时读；而后，对于不能接受过时读的语句，再使用等 GTID 或等位点的方案。

但话说回来，过时读在本质上是由一写多读致使的。在实际应用中，可能会有别的不须要等待就能够水平扩展的数据库方案，但这每每是用牺牲写性能换来的，也就是须要在读性

能和写性能中取权衡。

最后 ，我给你留下一个问题吧。

假设你的系统采用了咱们文中介绍的最后一个方案，也就是等 GTID 的方案，如今你要对主库的一张大表作 DDL，可能会出现什么状况呢？为了不这种状况，你会怎么作呢

你能够把你的分析和方案设计写在评论区，我会在下一篇文章跟你讨论这个问题。感谢你的收听，也欢迎你把这篇文章分享给更多的朋友一块儿阅读。

9、上期问题时间

上期给你留的问题是，在 GTID 模式下，若是一个新的从库接上主库，可是须要的 binlog已经没了，要怎么作？

@某、人同窗给了很详细的分析，我把他的回答略作修改贴过来。

1. 若是业务容许主从不一致的状况，那么能够在主库上先执行 show global variableslike ‘gtid_purged’，获得主库已经删除的 GTID 集合，假设是 gtid_purged1；而后先在从库上执行 reset master，再执行 set global gtid_purged=‘gtid_purged1’；最后执行 start slave，就会从主库现存的 binlog 开始同步。binlog 缺失的那一部分，数据在从库上就可能会有丢失，形成主从不一致。
2. 若是须要主从数据一致的话，最好仍是经过从新搭建从库来作。
3. 若是有其余的从库保留有全量的 binlog 的话，能够把新的从库先接到这个保留了全量
binlog 的从库，追上日志之后，若是有须要，再接回主库。
4. 若是 binlog 有备份的状况，能够先在从库上应用缺失的 binlog，而后再执行 startslave。

评论区留言点赞板：

@悟空 同窗级联实验，验证了 seconds_behind_master 的计算逻辑。

@_CountingStars 问了一个好问题：MySQL 是怎么快速定位 binlog 里面的某一个 GTID 位置的？答案是，在 binlog 文件头部的 Previous_gtids 可
以解决这个问题。

@王朋飞 同窗问了一个好问题，sql_slave_skip_counter 跳过的是一个event，因为 MySQL 总不能执行一半的事务，因此既然跳过了一个event，就会跳到这个事务的末尾，所以 set globalsql_slave_skip_counter=1;start slave 是能够跳过整个事务的。