主从复制：在实际的生产中，为了解决Mysql的单点故障以及提高MySQL的整体服务性能，一般都会采用主从复制。即：对数据库中的数据、语句做备份。
Mysql的主从复制中主要有三个线程：master（binlog dump thread）、slave（I/O thread 、SQL thread），Master一条线程和Slave中的两条线程。
主从复制过程
master主要负责Master库中有数据更新的时候，会按照binlog格式，将更新的事件类型写入到主库的binlog文件中。Master会创建log dump线程通知Slave主库中存在数据更新。
I/O thread线程在Slave中创建，该线程用于请求Master，Master会返回binlog的名称以及当前数据更新的位置、binlog文件位置的副本。然后，将binlog保存在 relay log（中继日志） 中，中继日志也是记录数据更新的信息。
SQL线程也是在Slave中创建的，当Slave检测到中继日志有更新，会将更新的内容同步到Slave数据库中，保证了主从的数据的同步。
主从复制策略
同步策略：Master会等待所有的Slave都回应后才会提交，这个主从的同步 的性能会严重的影响。
半同步策略：Master至少会等待一个Slave回应后提交。
异步策略：Master不用等待Slave回应就可以提交。
延迟策略：Slave要落后于Master指定的时间。
对于不同的业务需求，有不同的策略方案，但是一般都会采用最终一致性，不会要求强一致性，强一致性会严重影响性能。
主从复制高延迟的原因
master 服务器高并发，形成大量事务
网络延迟
主从硬件设备导致（cpu 主频、内存 io、硬盘 io）
本来就不是同步复制、而是异步复制
主从复制高延迟的解决办法
从库优化 Mysql 参数。比如增大 innodb_buffer_pool_size，让更多操作在 - mysql 内存中完成，减少磁盘操作
从库使用高性能主机（高性能 cpu、大内存），避免使用虚拟云主机，使用物理主机，提升 I/O 吞吐量
从库使用 SSD 磁盘
网络优化，避免跨机房实现同步
读写分离：读写分离是让主数据库处理事务性增、删、改操作（INSERT、UPDATE、DELETE），而从数据库处理查（SELECT） 操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库中。
读写分离原因：读写量很大，为了提升数据库读写性能，将读写进行分离；多机房下如果写少读多，同时基于数据一致性考虑，只有一个主库存入所有的数据写入，本地再做从库提供读取，减少多机房间直接读取带来的时延。
读写分离使用场景：程序使用数据库较多时，而更新少，查询多的情况下会考虑使用。利用数据库主从同步，再通过读写分离可以分担数据库压力，提高性能。
