mysql读写分离详解及同步延迟问题

1. 读写分离的目的

1.1 什么是读写分离
是将mysql多实例化，写数据时，将数据写入main服务，读请求时，从slave服务读取数据，将读和写拆分开，每次main收到写数据时，会将binlog日志同步到slave服务，slave服务再将binlog在自己的实例中执行，以达到数据是一致性的；

1.2 读写分离的场景
当数据库系统出现瓶颈时，有很多种优化方式，读写分离只能算是其中的一种，它主要解决的问题是，数据库的读多写少，读请求非常多，但是写请求非常少；为什么呢？我们分几种情况讨论：

1. 读多写少：
   1）并发读不需要事务，而写入数据需要事务， 假如写入数据是200ms，而读数据是10ms；1s内如果全是读请求，则可以达到100qps。如果1s内有2个写请求，qps可能就降低到60qps；
   2）此种情况下做读写分离，一个主库可以挂多个从库(假如3个)，那么此时1s的并发直接提升到300qps；
2. 写多读少：
   1）读写分离是多同mysql实例之间的同步是靠binlog日志的，如果写比较多，也就是同步binlog的次数会比较多，这种情况更容易产生主从延迟问题；
   2）即使想对这种情况做读写分离意义不大，因为再怎么分离，接收写请求的实例也只有一台，也提升不了写的并发量，如果做mysql集群实现多主模式，技术挑战可能更大；
3. 数据量多：
   表数据单过大，导致查询效果低，此种模式下做读写分离解决不了问题，因为读写分离每张表的内容是一模一样的；此时做sql优化和分库分表的方案可能会更好一些；

1.3 读写分离和数据缓存的区别
读写分离能提升数据库层面的并发能力和因为写请求阻塞导致读请求并发能力降低，而将数据放到缓存能减少DB层面的压力，缓解数据库的并发量；处理的问题的实制是不同的，一般项目中两种方案会结合使用；

2. 读写分离会遇到的问题

由单节点扩充为多节点，相当于由单节点拆分成分布式一样，会存在各种各样的问题需要处理：
1.1 主库宕机时，数据未同步到从库，造成数据的丢失
mysql提供了一种 半同步复制，就是主库写入binlog日志之后，将binlog同步到从库，然后从库将binlog写入relay log后返回一个ack（至少一个从库返回ack）给主库；
此时就解决了主库宕机时，从库未收到数据造成丢失的问题；但这种方式会存在性能问题，会降低主库的写入能力；

1.2 并行复制
所谓并行复制，指的是从库开启多个线程，并行读取 relay log 中不同库的日志，然后并行重放不同库的日志，注意这里是库级别的并行。

1.3 主从同步延迟问题
这个问题无论是面试还是工作中，只要提到读写分离必要考虑清楚的一个问题，至于延迟产生的原因我们先来聊一下：延迟有几个方面

1. 硬件原因；
2. 主库并发，从库单线程重放；
3. 网络原因；
4. 执行大的事务sql等；

如果你业务场景有插入之后，马上读取的需求，你可能需要对读写延迟问题做些处理，如果业务对这个短暂的延迟不影响，可以不处理；

解决延迟：

1. 多主方案降低主库的并发量；
2. 如果是多库，可以打开并行复制机制；
3. 写入主库立刻查询时，查询主库，超过一定时间后，读取从库；
4. 写入主库时，再将数据写入一个缓存中并设置超时时间，如果缓存可以查询到则直接返回（可能又遇到写入后如果立刻更改怎么保证缓存中数据一致性问题）；
5. mysql proxy的解决方案：master上做insert时，更新一张自增表，查询时，查询master和slave上的这张自增表的值是否一样，如果一样认为已经完成主从同步，否则读取主库；详细参考