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 避免主从复制的延迟
这咋办呢？其实解决方案有很多，核心思想都是 尽量不去从库查询数据。因此针对上述案例，就有如下方案：