读写分离有哪些坑？

---

前面文章提到，我们数据库结构一般会遵从，一主一备，一主多从的结构，备库目的是容灾，即主库挂了备库顶上，而从库是只读的，目的是读写分离，分担主库读的压力。

读写分离架构

• 读写分离架构一般分为客户端直连和带 proxy 的读写分离架构。

客户端直连

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

带 proxy 的读写分离

• 带 proxy 的架构，对客户端比较友好。客户端不需要关注后端细节，连接维护、后端信息维护等工作，都是由 proxy 完成的。但这样的话，对后端维护团队的要求会更高。而且，proxy 也需要有高可用架构。因此，带 proxy 架构的整体就相对比较复杂。目前看，趋势是往带 proxy 的架构方向发展的。

主从延迟处理方案

• 上面不论使用哪种架构，都会碰到这样的问题：由于主从可能存在延迟，客户端执行完一个更新事务后马上发起查询，如果查询选择的是从库的话，就有可能读到刚刚的事务更新之前的状态，这里来讨论一下过期读的处理方案。

强制走主库方案

• 强制走主库方案其实就是，将查询请求做分类。通常情况下，可以将查询请求分为这么两类：
  • 对于必须要拿到最新结果的请求，强制将其发到主库上。
  • 对于可以读到旧数据的请求，才将其发到从库上。
• 这个方案最大的问题在于，有时候你会碰到所有查询都不能是过期读的需求，比如一些金融类的业务。这样的话，你就要放弃读写分离，所有读写压力都在主库，等同于放弃了扩展性。

Sleep 方案

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

• 这个方案的假设是，大多数情况下主备延迟在 1 秒之内，做一个 sleep 可以有很大概率拿到最新的数据。这个方案一看就“不靠谱”，其实这个思路确实可以在一定程度上解决问题。但从严格意义上来说，这个方案存在的问题就是不精确。这个不精确包含了两层意思：

  • 如果这个查询请求本来 0.5 秒就可以在从库上拿到正确结果，也会等 1 秒；
  • 如果延迟超过 1 秒，还是会出现过期读。

• 总的来说，确实好像不靠谱。我们来继续介绍下面的方案

判断主备无延迟方案

• 要确保备库无延迟，通常有三种做法。
• 第一种方法，show slave status 结果里的 seconds_behind_master 参数的值，可以用来衡量主备延迟时间的长短。第一种确保主备无延迟的方法是，每次从库执行查询请求前，先判断 seconds_behind_master 是否已经等于 0。如果还不等于 0 ，那就必须等到这个参数变为 0 才能执行查询请求。
• 第二种方法，对比位点确保主备无延迟：
  • Master_Log_File 和 Read_Master_Log_Pos，表示的是读到的主库的最新位点；
  • Relay_Master_Log_File 和 Exec_Master_Log_Pos，表示的是备库执行的最新位点。
• 第三种方法，对比 GTID 集合确保主备无延迟：
  • Auto_Position=1 ，表示这对主备关系使用了 GTID 协议。
  • Retrieved_Gtid_Set，是备库收到的所有日志的 GTID 集合；
  • Executed_Gtid_Set，是备库所有已经执行完成的 GTID 集合。

---

笔记来源于《极客时间：MySQL实战45讲：读写分离有哪些坑？》