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