这次探索的问题：
- 什么是 Mysql主从同步？
- Mysql主从同步为什么会有主从延迟？
- 主从同步延迟解决方案？
🤞这次都给他拿下🤞
为什么 主从同步 会暴露出问题呢？ 主从同步虽然满足了性能上要求，但一致性可能会有问题。
正菜来了🛴🛴🛴
🍖Mysql主从同步是？
因为数据访问量的大量增长，单体数据库主键有点吃力了，采用主库写数据，从库读数据这种将读写分离开的主从架构便产生了。
常见主从同步有，一主一从，一主多从，多主一从，多主多从，这次拿一主多从举例。
🍕主从同步原理
涉及到两个重要文件
- binlog（二进制日志文件）
- relay log（中继日志文件）
🍕主从同步原理主从同步过程
- 主库将数据库中数据的变化写入到 binlog
- 从库连接主库
- 从库会创建一个 I/O 线程向主库请求更新的 binlog
- 主库会创建一个 binlog dump 线程来发送 binlog ，从库中的 I/O 线程负责接收
- 从库的 I/O 线程将接收的 binlog 写入到 relay log 中。
- 从库的 SQL 线程读取 relay log 同步数据本地（也就是再执行一遍 SQL ）
🍖为什么有主从同步延迟？
温馨提醒：这个主要有以下两点原因
🍕随机重放
MySQL的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，由于binlog是顺序写，所以效率很高。Slave的SQL Thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随机的，不是顺序的，成本高很多。所以SQL Thread线程的速度赶不上主库写binlog的速度，就会产生主从延迟
🍕锁等待
另一方面，由于SQL Thread也是单线程的，当主库的并发较高时，产生的DML数量超过slave的SQL Thread所能处理的速度，或者当slave中有大型query语句产生了锁等待那么延时就产生了。
🍖主从同步延迟解决方案
🍕强制读主库
如果你做的是类似支付这种对实时性要求非常高的业务，那么最直接的方法就是直接读主库，当然这种方法相当于从库做一个备份的功能了。
🍕延迟读
就是在写入之后，等一段时间再读，Eg：写入后同步的时间是0.5s，读取的时候可以设置1s后再读，但是这个方案主要存在的问题就是，不知道主从同步完成所需要的时间。
🍕降低并发
如果你理解了随机重放这个导致主从延迟的原因，那么就比较好理解了，控制主库写入的速度，主从延迟发生的概率自然就小了。{原因：因为主库中sql可能并发执行，可以控制并发速度}。
🍕并行复制
相比于上边的三种，相对比较好的解决方案了。
SQL 单线程进行重放时速度有限，那么能不能采用多线程的方式来进行重放呢？
MySQL 5.6 版本后，提供了一种并行复制的方式，通过将 SQL 线程转换为多个 work 线程来进行重放，这样就解决了主从延迟的问题。
🍚总结
常用的主从同步延迟解决方案：
🥖强制读主库
🥖延迟读
🥖降低并发
🥖并行复制(推荐)
