背景前段时间遇到一个线上问题。查了半天，发现是主从同步延迟导致的。所以我今天写了一篇文章来总结一下这个问题。你很有用。觉得还不错的话记得加个关注点个赞哦。思维导图常见的主从架构随着访问量的不断增加，单一数据库的能力已经捉襟见肘。因此，利用主库写入数据，从库读取数据，衍生出读写分离的主从架构。一主从一主多从一主从和一主多从是最常见的主从架构。它们实施起来简单有效。它们不仅可以实现高可用，还可以实现读写分离，从而提高集群的并发性。多主从双主复制级联复制主从同步原理想要了解主从同步原理，首先要记住两个非常重要的日志文件binlog（二进制日志文件）relaylog（中继日志file)主从同步进程从库生成2个线程，1个I/O线程，1个SQL线程；I/O线程请求主库的binlog，并将获取到的binlog日志写入中继日志（relaylog）文件；主库会生成一个日志转储线程，将binlogSQL线程传递给从库I/O线程。它会读取relaylog文件中的日志，解析成具体的操作，实现主从操作一致，最终数据一致；如何判断主从是否延迟，通过监控showslavestatus命令输出的Seconds_Behind_Master参数的值来判断：NULL，说明io_thread或者sql_thread失败了；0，值为零，说明主从复制良好；正值，说明主从已经经历了延迟，数字越大，说明从库延迟越严重。主从延迟随机重放的原因MySQL的主从复制是单线程操作。主库将DDL和DML产生的日志全部写入binlog。由于binlog是顺序写入的，所以效率非常高。从库的SQLThread在从库中重放主库的DDL和DML操作事件。DML和DDL的IO操作是随机的，不是顺序的，成本要高很多。所以SQLThread线程的速度跟不上主库学习binlog的速度，就会出现主从延迟锁等待。另一方面，由于SQLThread也是单线程的，当主库并发较高时，产生的DML量超过从SQL。Thread能够处理的速度，或者当slave中有大查询语句产生锁等待时，就会出现延迟。主从延时解决方案并行复制由于SQL单线程replay速度有限，是否可以采用多线程replay？MySQL5.6之后提供了并行复制的方式，通过将SQL线程转换为多个工作线程进行重放，解决了主从延迟问题，降低并发。如果理解了随机重播导致master延迟的原因，就更容易理解了。控制好主库的写入速度，自然会降低主从延迟的概率。如果你做的是对实时性要求非常高的业务，比如支付，最直接的方式就是直接读取主库。几句唠叨大家好，我是后端工程师小凡。如果您觉得文章对您有帮助，欢迎分享给您的朋友，给小凡点个赞。以下是我的公众号。有兴趣的可以关注一下。这就是小凡坚持下去的动力。谢谢大家。下次见！
