1 主从读写分离

当我们面临高并发的查询数据请求时，可以使用主从读写分离的方式，部署多个从库分摊读压力。

大部分互联网业务都是读多写少，因此优先考虑DB如何支撑更高并发查询，首先就需要区分读、写流量，这才方便针对读流量单独扩展，即主从读写分离。

若前端流量突增导致从库负载过高，DBA会优先做个从库扩容上去，这样对DB的读流量就会落到多个从库，每个从库的负载就降了下来，然后开发再尽力将流量挡在DB层之上。

Cache V.S MySQL读写分离

由于从开发和维护的难度考虑，引入缓存会引入复杂度，要考虑缓存数据一致性，穿透，防雪崩等问题，并且也多维护一类组件。所以推荐优先采用读写分离，扛不住了再使用Cache。

1.1 core

主从读写分离一般将一个DB的数据拷贝为一或多份，并且写入到其它的DB服务器中：

• 原始DB为主库，负责数据写入
• 拷贝目标DB为从库，负责数据查询

所以主从读写分离的关键：

• 数据的拷贝
  即主从复制
• 屏蔽主从分离带来的访问DB方式的变化
  让开发人员使用感觉依旧在使用单一DB

2 主从复制

MySQL的主从复制依赖于binlog，即记录MySQL上的所有变化并以二进制形式保存在磁盘上二进制日志文件。

主从复制就是将binlog中的数据从主库传输到从库，一般异步：主库操作不会等待binlog同步完成。

2.1 主从复制的过程

从库在连接到主节点时会创建一个I/O线程，以请求主库更新的binlog，并把接收到的binlog写入relay log文件，主库也会创建一个log dump线程发送binlog给从库

从库还会创建一个SQL线程，读relay log，并在从库中做回放，最终实现主从的一致性

使用独立的log dump线程是异步，避免影响主库的主体更新流程，而从库在接收到信息后并不是写入从库的存储，是写入一个relay log，这是为避免写入从库实际存储会比较耗时，最终造成从库和主库延迟变长。

• 主从异步复制的过程

基于性能考虑，主库写入流程并没有等待主从同步完成就返回结果，极端情况下，比如主库上binlog还没来得及落盘，就发生磁盘损坏或机器掉电，导致binlog丢失，主从数据不一致。不过概率很低，可容忍。

主库宕机后，binlog丢失导致的主从数据不一致也只能手动恢复。

主从复制后，即可：

• 在写入时只写主库
• 在读数据时只读从库

这样即使写请求会锁表或锁记录，也不会影响读请求执行。高并发下，可部署多个从库共同承担读流量，即一主多从支撑高并发读。

从库也能当成个备库，以避免主库故障导致数据丢失。

那无限制地增加从库就能支撑更高并发吗？

NO！从库越多，从库连接上来的I/O线程越多，主库也要创建同样多log dump线程处理复制的请求，对于主库资源消耗较高，同时受限于主库的网络带宽，所以一般一个主库最多挂3～5个从库。

2.2 主从复制的副作用

比如发朋友圈这一操作，就存在数据的：

• 同步操作
  如更新DB
• 异步操作
  如将朋友圈内容同步给审核系统

所以更新完主库后，会将朋友圈ID写入MQ，由Consumer依据ID在从库获取朋友圈信息再发给审核系统。

此时若主从DB存在延迟，会导致在从库取不到朋友圈信息，出现异常！

• 主从延迟对业务的影响示意图

2.3 避免主从复制的延迟

这咋办呢？其实解决方案有很多，核心思想都是 尽量不去从库查询数据。因此针对上述案例，就有如下方案：