寫這篇文章是因為之前有一次刪庫操作，需要進行批量洗掉資料，當時沒有控制好洗掉速度，導致產生了主從延遲，出現了一點小事故，
今天我們就來看看為什么會產生主從延遲以及主從延遲如何處理等相關問題，
坐好了，準備發車！
圖注：思維導圖
主從常見架構
隨著日益增長的訪問量，單臺資料庫的應接能力已經捉襟見肘，因此采用主庫寫資料，從庫讀資料這種將讀寫分離開的主從架構便隨之衍生了出來，
在生產環境中，常見的主從架構有很多種，在這里給大家介紹幾種比較常見的架構模式，
主從復制原理
了解了主從的基本架構及相關配置后，下面就要進入正題了，
對于主從來說，通常的操作是主庫用來寫入資料，從庫用來讀取資料，這樣的好處是通過將讀寫壓力分散開，避免了所有的請求都打在主庫上，同時通過從庫進行水平擴展使系統的伸縮性及負載能力也得到了很大的提升，
但是問題就來了，讀從庫時的資料要與主庫保持一致，那就需要主庫的資料在寫入后同步到從庫中，如何保持主庫與從庫的資料一致性，主庫又是通過什么樣的方式將資料實時同步到從庫的？
基本原理
Mysql 中主從復制時有兩個很重要的日志檔案：
-
binlog（二進制日志檔案）
-
relay log（中繼日志檔案）
在主從同步的程序中，主庫會將所有的操作事件記錄在 binlog 中，從庫通過開啟一個 I/O 執行緒保持與主庫的通信，并在一定時間間隔內探測 binlog 日志檔案是否發生改變，如果 binlog 日志發生了變化，主庫生成一個 binlog dump 執行緒向從庫 I/O 執行緒傳送 binlog，從庫上的 I/O 執行緒將 binlog 復制到自己的 relay log 中，最終由從庫中的 SQL 執行緒讀取 relay log 中的事件重放到從庫上，
主從延遲原因
上面的流程我們已經知道了主從復制的相關程序了，但是主庫有更新就會同步從庫，那為什么會出現主從延遲的情況呢？
隨機重放
Mysql 主庫中寫 binlog 的操作是順序寫的，之前我們提到過，磁盤的順序讀寫速度是很快的，同樣的，從庫中的 I/O 執行緒操作日志的速度效率也是很高的，但是別忘了，還有一個 SQL 執行緒來進行資料重放，而重放的程序是隨機寫盤的，到這里你應該就明白了吧，某一時刻 relay log 里的資料來不及重放進從庫，就會產生主從延遲的情況，
主庫并發高
知道了從庫中 SQL 執行緒的重放情況，對于主庫并發高導致主從延遲肯定就不難理解了，某一時刻，大量寫請求打到主庫上，意味著要不斷對 binlog 進行寫入，此時從庫中的 SQL 執行緒就會應接不暇，自然會產生主從延遲，
鎖等待
對于 SQL 單執行緒來說，當遇到阻塞時就會一直等待，直到執行成功才會繼續進行，如果某一時刻從庫因為查詢產生了鎖等待的情況，此時只有當前的操作執行完成后才會進行下面的操作，同理也就產生了主從延遲的情況，
主從延遲處理
知道了主從延遲的原因，接下來我們看看如何來進行處理，
并行復制
既然 SQL 單執行緒進行重放時速度有限，那么能不能采用多執行緒的方式來進行重放呢？MySQL 5.6 版本后，提供了一種并行復制的方式，通過將 SQL 執行緒轉換為多個 work 執行緒來進行重放，這樣就解決了主從延遲的問題，
降低主庫并發
你可能會說了，我現在用的低版本的資料庫，也沒法升版本啊，那我怎么整，對于主庫并發高的情況，這種方式你只能通過控制并發來解決延遲了，多用用 Redis，
讀主庫
這種情況你肯定不陌生，對于一些實時性要求比較高的資料，你總不能讀從庫去拿吧，萬一延遲個大半天，你不得貢獻自己的年終獎啊，
總結
主從復制原理
-
主從復制中有兩個很重要的日志檔案，binlog和relay log，分別位于主庫與從庫中，其中 binlog 是主從復制的基礎，通過將操作事件寫入 binlog 通過 I/O 執行緒傳送至從庫進行同步，
主從延遲原因
-
從庫中 SQL 執行緒重放的程序是隨機寫盤的，并且 SQL 執行緒是單執行緒的，因此資料來不及重放的話就會導致主從延遲，
-
主庫并發高會導致寫操作不斷寫入 binlog，對于 SQL 執行緒說可能會應接不暇，也會產生主從延遲，
-
重放程序中如果遇到鎖等待也是產生延遲的原因之一，
主從延遲處理
- MySQL 5.6版本以后通過并行復制的方式來解決 SQL 單執行緒產生的主從延遲問題，對于低版本來說，可以通過降低主庫的并發來解決，如果對資料實時性要求比較嚴格的話，可以通過讀主庫來達到目的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/246158.html
標籤：其他