《Mysql - 读写分离有哪些坑？》

一：读写分离

　　- 概念

　　　　-  读写分离的主要目标就是分摊主库的压力。

　　- 基本架构

　　　　-     - 

二：两种读写分离的架构特点

　　- 客户端直连方案

　　　　- 因为少了一层 proxy 转发，所以查询性能稍微好一点儿，并且整体架构简单，排查问题更方便。

　　　　- 但是这种方案，由于要了解后端部署细节，所以在出现主备切换、库迁移等操作的时候，客户端都会感知到，并且需要调整数据库连接信息。

　　　　- 你可能会觉得这样客户端也太麻烦了，信息大量冗余，架构很丑。

　　　　- 其实也未必，一般采用这样的架构，一定会伴随一个负责管理后端的组件，比如 Zookeeper，尽量让业务端只专注于业务逻辑开发。

　　- proxy 方案

　　　　- 带 proxy 的架构，对客户端比较友好。客户端不需要关注后端细节，连接维护、后端信息维护等工作，都是由 proxy 完成的。

　　　　- 但这样的话，对后端维护团队的要求会更高。而且，proxy 也需要有高可用架构。

　　　　- 因此，带 proxy 架构的整体就相对比较复杂。

三：什么是“过期读” ？

　　-  “在从库上会读到系统的一个过期状态”的现象，暂且称之为“过期读”。

四：处理 “过期读” 的方案？

　　- 强走主库方案

　　- sleep 方案；

　　- 判断主备无延迟方案；

　　- 配合 semi-sync 方案；

　　- 等主库位点方案；

　　- 等 GTID 方案。

五：强走主库方案

　　- 原理

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

　　　　- 对于必须要拿到最新结果的请求，强制将其发到主库上。

　　　　　　- 比如，在一个交易平台上，卖家发布商品以后，马上要返回主页面，看商品是否发布成功。

　　　　　　- 那么，这个请求需要拿到最新的结果，就必须走主库。

　　　　- 对于可以读到旧数据的请求，才将其发到从库上。

　　　　　　-  在这个交易平台上，买家来逛商铺页面，就算晚几秒看到最新发布的商品，也是可以接受的。那么，这类请求就可以走从库。

　　- 问题

　　　　- 这个方案最大的问题在于，有时候你会碰到“所有查询都不能是过期读”的需求，比如一些金融类的业务。

　　　　- 这样的话，你就要放弃读写分离，所有读写压力都在主库，等同于放弃了扩展性。

六：sleep 方案

　　- 原理

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

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

　　　　　　- 如如在客户端在下单完成后做1s的loading，其实等于变相的等待了从库1s。

　　- 问题

　　　　- sleep 方案确实解决了一定场景下的过期读问题。

　　　　- 但，从严格意义上来说，这个方案存在的问题就是不精确。

　　　　- 这个不精确包含了两层意思：

　　　　　　- 如果这个查询请求本来 0.5 秒就可以在从库上拿到正确结果，也会等 1 秒；

　　　　　　- 如果延迟超过 1 秒，还是会出现过期读。

七：判断主备无延迟方案

　　- 原理

　　　　- 通过 show slave status；结果

　　　　- 

　　- 对比  seconds_behind_master 判断主备无延迟（精度S）

　　　　- 每次从库执行查询请求前，先判断 seconds_behind_master 是否已经等于 0。

　　　　- 如果还不等于 0 ，那就必须等到这个参数变为 0 才能执行查询请求。

　　- 对比 点位 判断主备无延迟

　　　　-  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 更准确。

　　　　- 这几种办法并没有达到 “精确” 的程度，可能存在 主库已经执行，但是还没有发送给备库的情况，导致过期读。（通过 semi-sync 解决）

八： 等主库点位方案 / 等GTID方案

　　- 这两个方案都是 在备库执行，等待一定时间，如果在时间内 主库点位 / GTID 同步，则在备库执行，否则到主库执行。

九：小结

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

　　- 即使是最后等待位点和等待 GTID 这两个方案，虽然看上去比较靠谱儿，但仍然存在需要权衡的情况。

　　　　- 如果所有的从库都延迟，那么请求就会全部落到主库上，这时候会不会由于压力突然增大，把主库打挂了呢？

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

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

　　- 但话说回来，过期读在本质上是由一写多读导致的。

　　- 在实际应用中，可能会有别的不需要等待就可以水平扩展的数据库方案，但这往往是用牺牲写性能换来的，也就是需要在读性能和写性能中取权衡。