閱讀本文大概須要 3.7 分鐘。javascript
來自：萊烏php
寫這篇文章是由於以前有一次刪庫操做，須要進行批量刪除數據，當時沒有控制好刪除速度
，致使產生了主從延遲，出現了一點小事故。
今天咱們就來看看爲何會產生主從延遲以及主從延遲如何處理等相關問題。
隨着日益增加的訪問量，單臺數據庫的應接能力已經捉襟見肘。所以採用主庫寫數據，從庫讀數據這種將讀寫分離開的主從架構便隨之衍生了出來。
在生產環境中，常見的主從架構有不少種，在這裏給你們介紹幾種比較常見的架構模式。
瞭解了主從的基本架構及相關配置後，下面就要進入正題了。
對於主歷來說，一般的操做是主庫用來寫入數據，從庫用來讀取數據。這樣的好處是經過將讀寫壓力分散開，避免了全部的請求都打在主庫上。同時經過從庫進行水平擴展使系統的伸縮性及負載能力也獲得了很大的提高。
可是問題就來了，讀從庫時的數據要與主庫保持一致，那就須要主庫的數據在寫入後同步到從庫中。如何保持主庫與從庫的數據一致性，主庫又是經過什麼樣的方式將數據實時同步到從庫的？
binlog（二進制日誌文件）java
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。
這種狀況你確定不陌生，對於一些實時性要求比較高的數據，你總不能讀從庫去拿吧，萬一延遲個大半天，你不得貢獻本身的年終獎啊。
從庫中 SQL 線程重放的過程是隨機寫盤的，而且 SQL 線程是單線程的，所以數據來不及重放的話就會致使主從延遲。sql
主庫併發高會致使寫操做不斷寫入 binlog，對於 SQL 線程說可能會目不暇接，也會產生主從延遲。數據庫
重放過程當中若是遇到鎖等待也是產生延遲的緣由之一。微信
推薦閱讀：
架構
如何從一張外國軍車照片，判斷它要去哪裏？
一個比 c3p0 快200倍的數據庫鏈接池，這麼牛？
5T技術資源大放送！包括但不限於：C/C++，Linux，Python，Java，PHP，人工智能，單片機，樹莓派，等等。在公衆號內回覆「2048」，便可免費獲取！！
微信掃描二維碼，關注個人公衆號
朕已閱
本文分享自微信公衆號 - 程序員的成長之路（cxydczzl）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。