背景
前段時間遇到一個線上問題，后來排查好久發現是因為主從同步延遲導致的，所以今天寫一篇文章總結一下這個問題希望對你有用。如果覺得還不錯,記得加個關注點個贊哦
思維導圖
常見的主從架構
隨着日益增長的訪問量，單台數據庫的能力已經捉襟見肘。因此采用主庫寫數據，從庫讀數據這種將讀寫分離開的主從架構便隨之衍生了出來。
一主一從
一主多從
一主一從和一主多從是最常見的主從架構，實施起來簡單並且有效，不僅可以實現高可用，還能讀寫分離，進而提升集群的並發能力。
多主一從
雙主復制
級聯復制
主從同步原理
想要了解主從同步原理，首先得記住兩個很重要的日志文件
-
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 線程來進行重放，這樣就解決了主從延遲的問題 
降低並發
如果你理解了隨機重放這個導致主從延遲的原因，那么就比較好理解了，控制主庫寫入的速度，主從延遲發生的概率自然就小了。
讀主庫
如果你做的是類似支付這種對實時性要求非常高的業務，那么最直接的方法就是直接讀主庫。
幾句嘮叨
大家好，我是小飯，一枚后端工程師。如果覺得文章對你有一點點幫助，歡迎分享給你的朋友，也給小飯點個贊，下面是我的公眾號，感興趣可以關注，這是小飯堅持下去的動力，謝謝大家，我們下次見！
