Mysql 45讲学习笔记（二十八）读写分离

Mysql 45讲学习笔记（二十八）读写分离

一.读写分离的两种模式

1、客户端（client）主动做负载均衡

2.mysql通过中间代理层proxy 根据请求类型和上下文决定请求的分发路由

客户端直连和带proxy的读写分离架构

客户端直连方案，查询性能好，但是需要了解后端部署细节主备切换，库迁移等操作客户端都会感知，需要调整数据库连接信息、这样客户端麻烦，信息大量冗余，架构丑一定会伴随着管理后端的组件，Zookeeper，后端专注业务逻辑开发

proxy架构

对客户端友好，客户端不需要感知后端细节，连接维护，后端信息维护等工作都是proxy完成

二.过期读

从库会读到系统的过期状态

三.强制走主库方案

将查询请求分类：

对于必须要拿到最新结果的请求，强制其发到主库上对于可以读到旧数据的请求，才将其发到从库上

四.Sleep方案

主库更新后，读从库之前先sleep一下具体方案是：类似执行一条select sleep（1）命令

最佳实践：

以卖家发布商品为例，商品发布后，Ajax（Asynchronous JavaScript + XML，异步 JavaScript 和 XML）直接把客户端输入的内容作为"新商品"显示在页面上，不会真正进行数据库查询卖家直接通过显示来确认产品发布成功，等卖家再去看看的时候就达到了sleep的目的，解决过期读的问题

存在问题：

如果这个查询请求本来0.5就可以从库拿到正确结果，也会等1s如果延迟超过1s，也会出现过期读

五.判断主备无延迟方案

每次从库执行查询请求前，先判断 seconds_behind_master 是否已经等于 0。如果还不等于 0，那就必须等到这个参数变为 0 才能执行查询请求。对比位点确保主备无延迟

六.配合 semi-sync（半同步复制）------增加确认状态

semi-sync 设计原理：

事务提交的时候，主库将binlog发给从库从库收到binlog后，发给主库一个ack，表示收到了主库收到ack以后，才给客户端返回"事务完成"确认

semi-sync+ 位点判断的方案存在问题：

只会一主一备场景，在一主多从场景，主库只要等到一个从库的ack，就开始给客户端返回确认如果查询落到其他从库上，就导致过期读

最严重的问题：

业务更新的高峰期，主库的位点或者GITD集合更新很快，导致等值判断一直不成立，从库迟迟无法响应查询请求的问题

七.等主库位点方案

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

返回正整数M。表示命令执行开始，到应用file和pos的binlog位置，执行了多少事务

如果执行期间，备库同步线程发生异常，则返回NULL如果等待超过N秒，就返回-1；刚开始执行的时候，发现已经执行过这个位置，就返回0

根据该命令执行的优化方案流程：

trx1 事务更新完成后，马上执行 show master status 得到当前主库执行到的 File 和 Position；

选定一个从库执行查询语句；

在从库上执行 select master_pos_wait(File, Position, 1)；

如果返回值是 >=0 的正整数，则在这个从库执行查询语句；

否则，到主库执行查询语句。

trx1事务更新完成后，马上执行show master status得到当前主库执行的File和Position选定一个从库执行查询语句在从库上执行select master_pos_wait(File, Position, 1)；如果返回值>=0,则在从库执行查询语句否则到主库执行查询语句

八.GTID 方案

select wait_for_executed_gtid_set(gtid_set,1);

等待，直到这个库执行的事务中包含传入的gtid_set,返回0；超时返回1

优化后的执行方案：

trx1事务更新完成后，从返回包直接获取这个事务 的GTID，记为gtid1选定一个从库执行查询语句在从库执行select wait_for_executed_gtid_set(gtid1, 1)如果返回值是0，则在这个从库执行查询语句否则到主库执行查询语句

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。