Notes

Exploring note

0%

读写分离导致的过期读问题

发表于 更新于 分类于
本文字数： 3.4k 阅读时长 ≈ 6 分钟
主备延迟在读写分离架构中引发的问题

读写分离的主要目标就是分摊主库的压力。两种架构：

  • 客户端(client)主动做负载均衡，这种模式下一般会把数据库的连接信息放在客户端的连接层，由客户端来选择后端数据库进行查询。
  • 在MySQL和客户端之间有一个中间层proxy，客户端只连接proxy，由proxy根据请求类型和上下文决定请求的分发路由。

架构对比：

  1. 客户端直连方案，因为少了一层proxy转发，查询性能稍微好一点，并且整体架构简单，排查问题更方便。缺点由于要了解后端部署细节，在出现主备切换、库迁移等操作时，客户端都会感知到，并且需要调整数据库连接信息。一般采用这样的架构，一定会伴随一个管理后端的组件，比如Zookeeper，处理冗余的配置信息，尽量让业务端只专注于业务逻辑开发。
  2. 带proxy的架构，对客户端比较友好。客户端不需要关注后端细节，连接维护、后端信息维护等工作，都是由proxy完成的。缺点对后端维护团队的要求会更高。而且proxy本身也需要有高可用架构，整体比较复杂。

由于主从可能存在延迟，客户端执行完一个更新事务后马上发起查询，如果查询选择的是从库的话，就有可能读到刚刚的事务更新之前的状态。这种在从库上会读到系统的一个过期状态的现象，称为过期读。

主从延迟是不能100%避免。但客户端希望查询从库的数据结果，跟查主库的数据结果时一样的。

强制走主库方案

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

  1. 对于必须要要拿到最新结果的请求，强制将其发到主库上。在一个交易平台上，卖家发布商品以后，马上要返回主页面，看商品是否发布成功。这个请求需要拿到最新的结果，就必须走主库。
  2. 对于可以读到旧数据的请求，才将其发到从库上。在这个交易平台上，买家来逛商铺页面，就算晚几秒看到最新发布的商品，也是可以接受的。这类请求可以走从库。

问题：针对“所有查询都不能是过期读”的需求，金融类业务。需要放弃读写分离，放弃扩展性，所有读写压力都在主库。

sleep方案

主库更新后，读从库之前先sleep一下，具体方案就是，类似于执行一条select sleep(1)命令。方案的前提是，大多数情况下主备延迟在1秒之内，做一个sleep可以有很大概率拿到最新的数据。

卖家发布商品，商品发布后，用Ajax(Asynchronous JacaScript + XML,异步JavaScript和XML)直接把客户端输入的内容作为“新的商品”显示在页面上，而不是真正的去数据库做查询。卖家可以通过这个显示，来确认产品已经发布成功了，等卖家再刷新页面，去查看商品的时候，已经过了一段时间，达到了类似sleep的目的，解决了过期读的问题。

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

判断主备无延迟方案

show slave status结果里的seconds_behind_master参数的值，可以用来衡量主备延迟时间的长短。

判断seconds_behind_master确保主备无延迟

每次从库执行查询请求前，先判断seconds_behind_master是否已经对于0。如果还不等于0，就必须等到这个参数变为0才能执行查询请求。

问题：SBM的单位是秒，精度不够。

对比位点确保主备无延迟

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

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

在执行查询请求前，先判断从库是否同步完成的方法，相比于sleep方案，准确度有提升，但达不到“精确”的程度。

一个事务的binlog在主备之间的状态：

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

本方案中判断主备无延迟的逻辑，是备库收到的日志都执行完成了。但是还有一部分日志，处于客户端已经收到提交确认，而备库还没收到日志的状态。但从库认为已经没有同步延迟，客户端在从库上执行查询请求却查不到数据。

配合semi-sync方案

半同步复制：semi-sync replication。

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

如果启用了semi-sync，就表示所有给客户端发送过确认的事务，都确保了备库已经收到了这个日志。
半同步复制也解决了普通模式下主库掉电，来不及发送给从库的binlog导致系统数据丢失的问题。

semi-sync配合关于位点(或者GTID)的判断，就能够确定在从库上执行的查询请求，可以避免过期读。

问题1：半同步复制+位点判断的方案，只对一主一备的场景是成立的。在一主多从场景中，主库只要等到一个从库的ack，就开始给客户端返回确认。此时，在从库上执行查询请求有两种情况：

  1. 如果查询是落在这个响应了ack的从库上，是能够确保读到最新数据；
  2. 但如果是查询落到其他从库上，它们可能还没有收到最新的日志，就会产生过期读的问题。

问题2：在业务更新的高峰期，主库的位点或者GTID集合更新很快，那么上面的两个位点等值判断就会一直不成立，很可能出现从库上迟迟无法响应查询请求，而过度等待的情况。

等主库位点方案

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

  1. 它是在从库执行的；
  2. 参数file和pos指的是主库上的文件名和位置；
  3. timeout可选，设置为正整数N，表示这个函数最多等待N秒。

这个命令正常返回的结果是一个正整数M，表示从命令开始执行，到应用完file和pos表示的binlog位置，执行了多少事务。其他异常返回：

  1. 如果执行期间，备库同步线程发生异常，则返回NULL；
  2. 如果等待超过N秒，就返回-1；(从库的延迟时间不可控，不能无限等待，等待超时，就应该放弃，然后到主库上去查)
  3. 如果刚开始执行的时候，就发现已经执行过这个位置了，则返回0。

示例：
先执行trx1，再执行一个查询请求的逻辑，要保证能够查到正确的数据：

  1. trx1事务更新完成后，马上执行show master status得到当前主库执行到的File和Position；
  2. 选定一个从库执行查询语句；
  3. 在从库上执行select master_pos_wait(File, Position, 1)；(最多等待一秒)
  4. 如果返回值是>=0的正整数，则在这个从库上执行查询语句；
  5. 否则，到主库上执行查询语句。

问题：如果所有的从库都延迟超过了1秒，查询压力都跑到主库上了。否则就超时放弃。

等GTID方案

数据库开启了GTID模式，对应等主库位点的等GTID方案。

select wait_for_executed_gtid_set(gtid_set, 1);

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

对比等主库位点，执行完事务后，还要主动去主库自行show master status。从MySQL5.7.6版本开始，允许在执行完更新类事务后，把这个事务的GTID返回给客户端，这样等GTID的方案可以减少一次查询。

示例：

  1. trx1事务更新完成后，从返回包直接获取这个事务的GTID，记为gtid1；(将参数session_track_gtids设置为OWN_GTID，然后通过API接口mysql_session_track_get_first从返回包解析出GTID的值)
  2. 选定一个从库执行查询语句；
  3. 在从库上执行select wait_for_executed_gtid_set(gtid1, 1)；
  4. 如果返回值是0，则在这个从库执行查询语句；
  5. 否则，到主库执行查询语句。

问题：与等主库位点一样。超时放弃或者直接到主库查询。