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