一、读写分离：
1、基本结构：
<1>、客户端直连：
<2>、带proxy的读写分离架构：
1、目的：
分摊主库的压力。
对于不带proxy的读写分离架构，客户端（client）主动做负载均衡，这种模式下一般会把数据库的连接信息放在客户端的连接层。也就是说，由客户端来选择后端数据库进行查询。
对于带proxy的读写分离架构，客户端只连接proxy， 由proxy根据请求类型和上下文决定请求的分发路由。
2、客户端直连和带proxy的读写分离架构，各自特点：
<1>、客户端直连方案：
①、少了一层proxy转发，所以查询性能稍微好一点儿。
②、并且整体架构简单，排查问题更方便。
③、由于要了解后端部署细节，所以在出现主备切换、库迁移等操作的时候，客户端都会感知到，并且需要调整数据库连接信息。
④、一般采用这样的架构，一定会伴随一个负责管理后端的组件，比如Zookeeper，尽量让业务端只专注于业务逻辑开发。
<2>、带proxy的架构：
①、对客户端比较友好。客户端不需要关注后端细节，连接维护、后端信息维护等工作，都是由proxy完成的。
②、对后端维护团队的要求会更高。
③、proxy需要有高可用架构。带proxy架构的整体就相对比较复杂。
二、过期读：
1、过期读的含义：
由于主从可能存在延迟，客户端执行完一个更新事务后马上发起查询，如果查询选择的是从库的话，就有可能读到刚刚的事务更新之前的状态。这种“在从库上会读到系统的一个过期状态”的现象，称之为“过期读”。
2、过期读的处理方案：
<1>、强制走主库方案：
强制走主库方案其实就是将查询请求做分类：
①、对于必须要拿到最新结果的请求，强制将其发到主库上。比如，在一个交易平台上，卖家发布商品以后，马上要返回主页面，看商品是否发布成功。那么，这个请求需要拿到最新的结果，就必须走主库。
②、对于可以读到旧数据的请求，才将其发到从库上。在这个交易平台上，买家来逛商铺页面，就算晚几秒看到最新发布的商品，也是可以接受的。那么，这类请求就可以走从库。
注意：有时候会碰到“所有查询都不能是过期读”的需求，这时就要放弃读写分离，所有读写压力都在主库，等同于放弃了扩展性。
<2>、sleep方案：
类似于执行一条select sleep(1)命令。这个方案的假设是，大多数情况下主备延迟在1秒之内，做一个sleep可以有很大概率拿到最新的数据。
注意：
如果这个查询请求本来0.5秒就可以在从库上拿到正确结果，也会等1秒；
如果延迟超过1秒，还是会出现过期读。
<3>、判断主备无延迟方案：
①、每次从库执行查询请求前，先判断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集合。
如果这两个集合相同，表示备库接收到的日志都已经同步完成。
注意：还是有可能出现过期读的。
<4>、配合semi-sync方案：
(1)、semi-sync replication(半同步复制)原理：
ↈ、事务提交的时候，主库把binlog发给从库；
ↈ、从库收到binlog以后，发回给主库一个ack，表示收到了；
ↈ、主库收到这个ack以后，才能给客户端返回“事务完成”的确认。
也就是说，如果启用了semi-sync，就表示所有给客户端发送过确认的事务，都确保了备库已经收到了这个日志。
(2)、semi-sync+位点判断的方案在一主多从场景中，主库只要等到一个从库的ack，就开始给客户端返回确认。这时，在从库上执行查询请求，就有两种情况：
ↈ、如果查询是落在这个响应了ack的从库上，是能够确保读到最新数据；
ↈ、但如果是查询落到其他从库上，它们可能还没有收到最新的日志，就会产生过期读的问题。
如果在业务更新的高峰期，主库的位点或者GTID集合更新很快，那么上面的两个位点等值判断就会一直不成立，很可能出现从库上迟迟无法响应查询请求的情况。
(3)、semi-sync配合判断主备无延迟的方案，存在的问题：
ↈ、一主多从的时候，在某些从库执行查询请求会存在过期读的现象；
ↈ、在持续延迟的情况下，可能出现过度等待的问题。
<5>、等主库位点方案：
(1)、命令：select master_pos_wait(file, pos[, timeout]);的逻辑：
ↈ、它是在从库执行的；
ↈ、参数file和pos指的是主库上的文件名和位置；
ↈ、timeout可选，设置为正整数N表示这个函数最多等待N秒。
(2)、命令：select master_pos_wait(file, pos[, timeout]);的返回结果：
ↈ、正常返回结果是一个正整数M，表示从命令开始执行，到应用完file和pos表示的binlog位置，执行了多少事务。
ↈ、如果执行期间，备库同步线程发生异常，则返回NULL；
ↈ、如果等待超过N秒，就返回-1；
ↈ、如果刚开始执行的时候，就发现已经执行过这个位置了，则返回0。
<6>、等GTID方案：
(1)、命令：select wait_for_executed_gtid_set(gtid_set, 1);的逻辑：
ↈ、等待，直到这个库执行的事务中包含传入的gtid_set，返回0；
ↈ、超时返回1。
(2)、MySQL在执行事务后，返回包中如何带上GTID：
将参数session_track_gtids设置为OWN_GTID，然后通过API接口mysql_session_track_get_first从返回包解析出GTID的值即可。
