最近项目上线，遇到了主从问题。按理说公司基建不至于出现这种问题，但就是出现了。可能因为用的不是原生的MySQL吧。主从延迟会给前端和服务端带来很多问题，需要花费时间用工程手段来解决，我认为这是很不合理的。
举几个因为主从延迟会导致问题场景：
凡是像这种操作后立即获取的，全会有问题。
为什么要有主从
MySQL数据库的主从（Master-Slave）架构主要是为了实现数据的高可用性（High Availability）和读写分离，具体的原因如下：
主从如何同步
下面是一个update 语句在主节点 A 执行，然后同步到从节点 B 的完整流程图
从库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程，专门用于服务从库 B的这个长连接。一个事务日志同步的完整过程是这样的：
在从库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量。
在从库 B 上执行 start slave 命令，这时候从库会启动两个线程，就是图中的 io_thread 和 sql_thread。其中 io_thread 负责与主库建立连接。
主库 A 校验完用户名、密码后，开始按照从库 B 传过来的位置，从本地读取 binlog，发给 B。
从库 B 拿到 binlog 后，写到本地文件，称为中转日志（relay log）。
sql_thread 读取中转日志，解析出日志里的命令，并执行。
为什么会主从延迟
什么是主从延迟？
主库 A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1;
之后传给从库 B，我们把从库 B 接收完这个 binlog 的时刻记为 T2;
从库 B 执行完成这个事务，我们把这个时刻记为 T3。
所谓主从延迟，就是同一个事务，在从库执行完成的时间和主库执行完成的时间之间的差值，也就是 T3-T1。
你可以在从库上执行 show slave status 命令，它的返回结果里面会显示seconds_behind_master，用于表示当前从库延迟了多少秒。
在网络正常的时候，日志从主库传给从库所需的时间是很短的，即 T2-T1的值是非常小的。也就是说，网络正常情况下，主从延迟的主要来源是从库接收完 binlog和执行完这个事务之间的时间差。
主从延迟来源
如何解决
一般的主从结构如下：
一旦出现主从延迟问题，有如下解决方案
强制走主库方案 - 有点可行
- 优点：能够区分场景，压力可控
- 缺点：
- 前后端都得改动。前端判断是否走主库，服务端判断指定场景走查主库
- 后续维护也比较麻烦
- 有时前端无法判断出场景，如进详情页，前端无法判断是刚创建完跳转的还是打开的是早已创建的
- 优点：简单便捷
- 缺点：不区分具体场景，主库压力大
- 优点：相对简单
- 缺点：无法处理所有场景，如list的场景，因为必然有数据，但并不知道是否准确
sleep 方案 - 有点可行
- 优点：简单便捷
- 缺点：用户体验不好
- 优点：逻辑比较通顺、清晰
- 缺点：
- 前端需要实现多套逻辑。如虽然是详情，但至少可能来自创建和详情接口；在成员列表中删除member成功后就直接不显示，不再调用list接口
- 维护成本高，如对于详情页，如果后续详情也变更，创建和详情接口如何保持一致
- 无法处理所有场景，如创建空间后获取成员列表（至少有自己）
判断主从延迟方案 - 有的可行
- 优点：
- 前端无需改动，服务端改动相对可控，而且设置为弱依赖，所以问题应该不大
- 能解决大部分问题
- 缺点：
- 服务端需要根据场景记录、读取redis
- 有一定概率增加主库压力，但总体可控
- 每次从库执行查询请求前，先判断seconds_behind_master 是否已经等于 0。如果还不等于 0 ，那就必须等到这个参数变为0 才能执行查询请求。可以使用 show slave status。
- 对比位点确保主从无延迟
- 对比 GTID 集合确保主从无延迟
这种方式感觉不太现实
- 实现上成本高
- 仍然有过期读问题。因为上面判断主从无延迟的逻辑，是“从库收到的日志都执行完成了”。但是，从 binlog在主从之间状态的分析中，不难看出还有一部分日志，处于客户端已经收到提交确认，而从库还没收到日志的状态。
- 如果在业务更新的高峰期，主库的位点或者 GTID 集合更新很快，那么上面的两个位点等值判断就会一直不成立，很可能出现从库上迟迟无法响应查询请求的情况
主从无延迟方案 + semi-sync 方案 能解决过期读问题。
semi-sync 做了这样的设计：
-
事务提交的时候，主库把 binlog 发给从库；
-
从库收到 binlog 以后，发回给主库一个 ack，表示收到了；
-
主库收到这个 ack 以后，才能给客户端返回“事务完成”的确认。
这样，semi-sync 配合前面关于位点的判断，就能够确定在从库上执行的查询请求，可以避免过期读。
但这种方案也不太现实，而且没有完全解决问题
- semi-sync+ 位点判断的方案，只对一主一从的场景是成立的。如果落到其它从库，还是会出现过期读
select master_pos_wait(file, pos[, timeout]);
这条命令的逻辑如下：
-
它是在从库执行的；
-
参数 file 和 pos 指的是主库上的文件名和位置；
-
timeout 可选，设置为正整数 N 表示这个函数最多等待 N 秒。
返回结果如下：
-
如果执行期间，从库同步线程发生异常，则返回 NULL；
-
如果等待超过 N 秒，就返回 -1；
-
如果刚开始执行的时候，就发现已经执行过这个位置了，则返回 0。
-
正常返回的结果是一个正整数 M，表示从命令开始执行，到应用完 file 和 pos 表示的 binlog 位置，执行了多少事务。
使用方法如下
-
trx1 事务在主库更新完成后，马上执行 show master status 得到当前主库执行到的 File 和Position；
-
选定一个从库执行查询语句；
-
在从库上执行 select master_pos_wait(File, Position, 1)；
-
如果返回值是 >=0 的正整数，则在这个从库执行查询语句
这种也不太现实，想想实现复杂度有多高。
select wait_for_executed_gtid_set(gtid_set, 1);
这条命令的逻辑是：
-
等待，直到这个库执行的事务中包含传入的 gtid_set，返回 0；
-
超时返回 1。
等 GTID 的执行流程为：
-
trx1 事务更新完成后，从返回包直接获取这个事务的 GTID，记为 gtid1；
-
选定一个从库执行查询语句；
-
在从库上执行 select wait_for_executed_gtid_set(gtid1, 1)；
-
如果返回值是 0，则在这个从库执行查询语句；
-
否则，到主库执行查询语句。
总结
真的是基建要做好，基建好了大家能把精力放到更重要的事情上。如果真出现主从延迟问题，能选择的方案其实比较少。要么就分场景走主库、要么前端sleep（偏临时方案）、要目服务端自己判断一下主从延迟情况。
这次我们选择redis打点记录，看看效果怎么样吧。
最后
大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）
我的个人博客为：shidawuhen.github.io/
往期文章回顾：
