一、主从架构
为什么咱们要进行读写拆散？集体感觉还是业务倒退到肯定的规模，驱动技术架构的改革，读写拆散能够加重单台服务器的压力，将读申请和写申请分流到不同的服务器，摊派单台服务的负载，进步可用性，进步读申请的性能。
下面这个图是一个根底的Mysql的主从架构，1主1备3从。这种架构是客户端被动做的负载平衡，数据库的连贯信息个别是放到客户端的连贯层，也就是说由客户端来抉择数据库进行读写
上图是一个带proxy的主从架构，客户端只和proxy进行连贯，由proxy依据申请类型和上下文决定申请的散发路由。
两种架构计划各有什么特点：
1.客户端直连架构，因为少了一层proxy转发，所以查问性能会比拟好点儿，架构简略，遇到问题好排查。然而这种架构，因为要理解后端部署细节，呈现主备切换，库迁徙的时候客户端都会感知到，并且须要调整库连贯信息
2.带proxy的架构，对客户端比拟敌对，客户端不须要理解后端部署细节，连贯保护，后端信息保护都由proxy来实现。这样的架构对后端运维团队要求比拟高，而且proxy自身也要求高可用，所以整体架构相对来说比较复杂
然而不管应用哪种架构，因为主从之间存在提早，当一个事务更新实现后马上发动读申请，如果抉择读从库的话，很有可能读到这个事务更新之前的状态，咱们把这种读申请叫做过期读。呈现主从提早的状况有多种，有趣味的同学能够本人理解一下，尽管呈现主从提早咱们同样也有应答策略，然而不能100%防止，这些不是咱们本次探讨的范畴，咱们次要讨论一下如果呈现主从提早，刚好咱们的读走的都是从库，咱们应该怎么应答？
首先我把应答的策略总结一下：
- 强制走主库
- sleep计划
- 判断主从无提早
- 等主库位点
- 等GTID计划
接下来基于上述的几种计划，咱们一一讨论一下怎么实现和有什么问题。
二、主从同步
在开始介绍主从提早解决方案前先简略的回顾一下主从的同步
上图示意了一个update语句从节点A同步到节点B的残缺过程
备库B和主库A保护了一个长连贯，主库A外部有一个线程，专门用来服务备库B的连贯。一个事务日志同步的残缺流程是：
1.在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、明码，以及要从哪个地位开始申请 binlog，这个地位蕴含文件名和日志偏移量。
2.在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io\_thread 和 sql\_thread。
3.其中 io_thread 负责与主库建设连贯。
4.主库 A 校验完用户名、明码后，开始依照备库 B 传过来的地位，从本地读取 binlog，发给 B。备库 B 拿到 binlog 后，写到本地文件，称为直达日志（relay log）。
5.sql_thread 读取直达日志，解析出日志里的命令，并执行。
上图中红色箭头，如果用色彩深浅示意并发度的话，色彩越深并发度越高，所以主从延迟时间的长短取决于备库同步线程执行直达日志(图中的relay log)的快慢。总结一下可能呈现主从提早的起因：
1.主库并发高，TPS大，备库压力大执行日志慢
2.大事务，一个事务在主库执行5s，那么同样的到备库也得执行5s，比方一次性删除大量的数据，大表DDL等都是大事务
3.从库的并行复制能力，Msyql5.6之前的版本是不反对并行复制的也就是上图的模型。并行复制也比较复杂，就不在这儿赘述了，大家能够自行温习理解一下。
三、主从提早解决方案
1.强制走主库
这种计划就是要对咱们的申请进行分类，通常能够将申请分成两类：
1.对于必须要拿到最新后果的申请，能够强制走主库
2.对于能够读到旧数据的申请，能够调配到从库
这种计划是最简略的计划，然而这种计划有一个毛病就是，对于所有的申请都不能是过期读的申请，那么所有的压力就又来到了主库，就得放弃读写拆散，放弃扩展性
2.sleep计划
sleep计划就是每次查问从库之前都先执行一下：select sleep(1)，相似这样的命令，这种形式有两个问题：
1.如果主从提早大于1s，那么仍然读到的是过期状态
2.如果这个申请可能0.5s就能在从库拿到后果，依然要等1s
这种计划看起来非常的不靠谱，不业余，然而这种计划的确也有应用的场景。
之前在做我的项目的时候，有这样么一种场景，就是咱们先写主库，写完后，发送一个MQ音讯，而后生产方接到音讯后，调用咱们的查问接口查数据，当然咱们也是读写拆散的模式，就呈现了查不到数据的状况，这个时候倡议生产方对音讯进行一个提早生产，比方提早30ms，而后问题就解决了，这种形式相似sleep计划，只不过把sleep放到了调用方
3.判断主从无提早计划
- 命令判断
show slave status，这个命令是在从库上执行的，执行的后果外面有个seconds\_behind\_master字段，这个字段示意主从提早多少s,留神单位是秒。所以这种计划就是通过判断以后这个值是否为0，如果为0则间接查问获取后果，如果不为0，则始终期待，直到主从提早变为0
因为这个值是秒级的，然而咱们的一些场景下是毫秒级的申请，所以通过这个形式判断，不是特地准确
- 比照位点判断主从无提早
上图是执行一次show slave status 局部后果
- 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这两组值完全一致，示意主从之间是没有提早的
3)比照GTID判断主从无提早
- Auto_Position：1示意这对主从之间启用了GTID协定
- Retrieved\_Gtid\_Set:示意从库接管到的所有的GTID的汇合
- Executed\_Gtid\_Set:示意从库执行实现的所有的GTID汇合
通过比拟Retrieved\_Gtid\_Set和Executed\_Gtid\_Set汇合是否统一，来确定主从是否存在提早。
可见比照位点和比照GTID汇合，比sleep要精确一点儿，在查问之前都能够先判断一下是否接管到的日志都执行实现了，尽管准确度晋升了，然而还达不到准确，为啥这么说呢？
先回顾一下binlog在一个事物下的状态
1.主库执行实现，写入binlog，反馈给客户端
2.binlog被从主库发送到备库，备库接管到日志
3.备库执行binlog
咱们下面判断主备无提早计划，都是判断备库收到的日志都执行过了，然而从binlog在主备之间的状态剖析，能够看出，还有一部分日志处于客户端曾经收到提交确认，然而备库还没有收到日志的状态
这个时候主库执行了3个事物，trx1,trx2,trx3，其中
- trx1,trx2曾经传到从库，并且从库曾经执行实现
- trx3主库曾经执行实现，并且曾经给客户端回复，然而还没有传给从库
这个时候如果在从库B执行查问，依照下面咱们判断位点的形式，这个时候主从是没有提早的，然而还查不到trx3,严格说就是呈现了"过期读"。那么这个问题有什么办法能够解决么？
要解决这个问题，能够引入半同步复制，也就是semi-sync repliacation(参考：https://dev.mysql.com/doc/refman/8.0/en/replication-semisync.html)。
能够通过
show variables like '%rpl_semi_sync_master_enabled%'show variables like '%rpl_semi_sync_slave_enabled%'这两个命令来查看主从是否都开启了半同步复制。
semi-sync做了这样的设计：
1.事物提交的时候，主库把binlog发给从库
2.从库接管到主库发过来的binlog，给主库一个ack确认，示意收到了
3.主库收到这个ack确认后，才给客户端返回一个事物实现的确认
也就是启用了semi-sync，示意所有返回给客户端曾经确认实现的事物，从库都收到了binlog日志，这样通过semi-sync配合判断位点的形式，就能够确定在从库上的查问，防止了过期读的呈现。
然而semi-sync配合判断位点的形式，只实用一主一备的状况，在一主多从的状况下，主库只有收到一个从库的ack确认，就给客户端返回事物执行实现的确认，这个时候在从库上执行查问就有两种状况
- 如果查问刚好是在给主库响应ack确认的从库上，那么能够查问到正确的数据
- 然而如果申请落到其余的从库上，他们可能还没收到日志，所以仍然可能存在过期读
其实通过判断同步位点或者GTID汇合的计划，还存在一个潜在的问题，就是业务高峰期，主库的位点或者GITD汇合更新的十分快，那么两个位点的判断始终不相等，很可能呈现从库始终无奈响应查问申请的状况。
下面的两种计划在靠谱水平和精确性上都差了一点儿，接下来介绍两种绝对靠谱和准确一点儿的计划
4.等主库位点
要了解等主库位点，先介绍一条命令
select master_pos_wait(file, pos[, timeout]);这条命令执行的逻辑是：
1.首先是在从库执行的
2.参数file和pos是主库的binlog文件名和执行到的地位
3.timeout参数是非必须，设置为正整数N，示意这个函数最多等到N秒
这个命令执行后果M可能存在的状况：
- M>0示意从命令执行开始，到利用完file和pos示意的binlog地位，一共执行了M个事务
- 如果执行期间，备库的同步线程产生异样，则返回null
- 如果期待超过N秒，返回-1
- 如果刚开始执行的时候，发现曾经执行了过了这个pos，则返回0
当一个事务执行实现后，咱们要马上发动一个查问申请，能够通过上面的步骤实现：
1.当一个事务执行实现后，马上执行show master status，获取主库的File和Position
2.抉择一个从库执行查问
3.在从库上执行 select master\_pos\_wait(File,Poistion,1)
4.如果返回的值>=0，则在这个从库上执行
5.否则回主库查问
这里咱们假如，这条查问申请在从库上最多期待1s,那么如果1s内master\_pos\_wait返回一个大于等于0的数，那么就能保障在这个从库上能查到刚执行完的事务的最新的数据。
上述的步骤5是这类计划的兜底计划，因为从库的延迟时间不可控，不能有限期待，所以如果超时，就应该放弃，到主库查问。
可能有同学会觉的，如果所有的提早都超过1s，那么所有的压力都到了主库，的确是这样的，然而依照咱们设定的不容许呈现过期读，那么就只有两种抉择，要么超时放弃，要么转到主库，具体抉择哪种，须要咱们依据业务进行具体的剖析。
5.等GTID计划
如果数据库开启的GTID模式，那么相应的也有等GTID的计划
select wait_for_executed_gtid_set(gtid_set, 1);这条命令的逻辑是：
1.期待，直到这个库执行的事务中蕴含传入的giid_set汇合，返回0
2.超时返回1
在后面期待主库位点的计划中，执行完事务后，须要到主库执行show master status。从mysql5.7.6开始，容许事务执行实现后，把这个事务执行的GTID返回给客户端，这样期待GTIID的计划就缩小了一次查问。
这时等GTID计划的流程就变成这样：
1.事务执行实现后，从返回包解析获取这个事务的GTID,记为gtid1
2.选定一个从库执行查问
3.在从库上执行select wait\_for\_executed\_gtid\_set(gtid1,1)
4.如果返回0，则在这个从库上执行查问
5.否则回到主库查问
和期待主库位点计划一样，最初的兜底计划都是转到主库查问了，须要综合业务思考确定计划
下面的事物执行实现后，从返回的包中解析GTID，mysql其实没有提供对应的命令，能够参考Mysql提供的api(https://dev.mysql.com/doc/c-api/8.0/en/mysql-session-track-get-first.html),在咱们的客户端能够调用这个函数获取GTID
四、总结
以上简略介绍了读写拆散架构，和呈现主从提早后，如果咱们用的读写拆散的架构，那么咱们应该怎么解决这种状况，置信在日常咱们的主从还是或多或少的存在提早。下面介绍的几种计划，有些计划看上去非常不靠谱，有些计划做了一些斗争，然而都有理论的利用场景，须要咱们依据本身的业务状况，正当抉择对应的计划。
但话说回来，导致过期读的实质还是一写多读导致的，在理论的利用中，可能有别的不必期待就能够程度扩大的数据库计划，但这往往都是通过就义写性能取得的，也就是须要咱们在读性能和写性能之间做个衡量。
文中有不太谨严或者谬误的中央还望大家多多斧正。
作者：京东批发 尚有智
起源：京东云开发者社区 转载请注明起源