背景
前段时间遇到一个线上问题，后来排查好久发现是因为主从同步延迟导致的，所以今天写一篇文章总结一下这个问题希望对你有用。如果觉得还不错,记得加个关注点个赞哦
思维导图
思维导图
常见的主从架构
随着日益增长的访问量，单台数据库的能力已经捉襟见肘。因此采用主库写数据，从库读数据这种将读写分离开的主从架构便随之衍生了出来。
一主一从
一主多从
一主一从和一主多从是最常见的主从架构，实施起来简单并且有效，不仅可以实现高可用，还能读写分离，进而提升集群的并发能力。
多主一从
双主复制
级联复制
主从同步原理
想要了解主从同步原理，首先得记住两个很重要的日志文件
-
binlog（二进制日志文件）
-
relay log（中继日志文件）
主从同步过程
-
从库生成两个线程，一个I/O线程，一个SQL线程；
-
i/o线程去请求主库 的binlog，并将得到的binlog日志写到relay log（中继日志） 文件中；
-
主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog
-
SQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；
如何判断主从是否延时
通过监控 show slave status 命令输出的Seconds_Behind_Master参数的值来判断：
-
NULL，表示io_thread或是sql_thread有任何一个发生故障；
-
0，该值为零，表示主从复制良好；
-
正值，表示主从已经出现延时，数字越大表示从库延迟越严重。
主从延迟原因
随机重放
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语句产生了锁等待那么延时就产生了。
主从延迟解决办法
并行复制
既然 SQL 单线程进行重放时速度有限，那么能不能采用多线程的方式来进行重放呢？MySQL 5.6 版本后，提供了一种并行复制的方式，通过将 SQL 线程转换为多个 work 线程来进行重放，这样就解决了主从延迟的问题
降低并发
如果你理解了随机重放这个导致主从延迟的原因，那么就比较好理解了，控制主库写入的速度，主从延迟发生的概率自然就小了。
读主库
如果你做的是类似支付这种对实时性要求非常高的业务，那么最直接的方法就是直接读主库。
几句唠叨
大家好，我是小饭，一枚后端工程师。如果觉得文章对你有一点点帮助，欢迎分享给你的朋友，也给小饭点个赞，感兴趣可以关注我的公众号——程序员小饭。谢谢大家，我们下次见！