如何實現 MySQL 的讀寫分離？MySQL 主從複製原理的是啥？

• 2019 年 11 月 22 日
• 筆記

如何實現 MySQL 的讀寫分離？

其實很簡單，就是基於主從複製架構，簡單來說，就搞一個主庫，掛多個從庫，然後我們就單單只是寫主庫，然後主庫會自動把數據給同步到從庫上去。

MySQL 主從複製原理的是啥？

主庫將變更寫入 binlog 日誌，然後從庫連接到主庫之後，從庫有一個 IO 執行緒，將主庫的 binlog 日誌拷貝到自己本地，寫入一個 relay 中繼日誌中。接著從庫中有一個 SQL 執行緒會從中繼日誌讀取 binlog，然後執行 binlog 日誌中的內容，也就是在自己本地再次執行一遍 SQL，這樣就可以保證自己跟主庫的數據是一樣的。

這裡有一個非常重要的一點，就是從庫同步主庫數據的過程是串列化的，也就是說主庫上並行的操作，在從庫上會串列執行。所以這就是一個非常重要的點了，由於從庫從主庫拷貝日誌以及串列執行 SQL 的特點，在高並發場景下，從庫的數據一定會比主庫慢一些，是有延時的。所以經常出現，剛寫入主庫的數據可能是讀不到的，要過幾十毫秒，甚至幾百毫秒才能讀取到。

而且這裡還有另外一個問題，就是如果主庫突然宕機，然後恰好數據還沒同步到從庫，那麼有些數據可能在從庫上是沒有的，有些數據可能就丟失了。

所以 MySQL 實際上在這一塊有兩個機制，一個是半同步複製，用來解決主庫數據丟失問題；一個是並行複製，用來解決主從同步延時問題。

這個所謂半同步複製，也叫 semi-sync 複製，指的就是主庫寫入 binlog 日誌之後，就會將強制此時立即將數據同步到從庫，從庫將日誌寫入自己本地的 relay log 之後，接著會返回一個 ack 給主庫，主庫接收到至少一個從庫的 ack 之後才會認為寫操作完成了。

所謂並行複製，指的是從庫開啟多個執行緒，並行讀取 relay log 中不同庫的日誌，然後並行重放不同庫的日誌，這是庫級別的並行。

MySQL 主從同步延時問題（精華）

以前線上確實處理過因為主從同步延時問題而導致的線上的 bug，屬於小型的生產事故。

是這個么場景。有個同學是這樣寫程式碼邏輯的。先插入一條數據，再把它查出來，然後更新這條數據。在生產環境高峰期，寫並發達到了 2000/s，這個時候，主從複製延時大概是在小几十毫秒。線上會發現，每天總有那麼一些數據，我們期望更新一些重要的數據狀態，但在高峰期時候卻沒更新。用戶跟客服回饋，而客服就會回饋給我們。

我們通過 MySQL 命令：

show status

查看 Seconds_Behind_Master，可以看到從庫複製主庫的數據落後了幾 ms。

一般來說，如果主從延遲較為嚴重，有以下解決方案：

• 分庫，將一個主庫拆分為多個主庫，每個主庫的寫並發就減少了幾倍，此時主從延遲可以忽略不計。
• 打開 MySQL 支援的並行複製，多個庫並行複製。如果說某個庫的寫入並發就是特別高，單庫寫並發達到了 2000/s，並行複製還是沒意義。
• 重寫程式碼，寫程式碼的同學，要慎重，插入數據時立馬查詢可能查不到。
• 如果確實是存在必須先插入，立馬要求就查詢到，然後立馬就要反過來執行一些操作，對這個查詢設置直連主庫。不推薦這種方法，你要是這麼搞，讀寫分離的意義就喪失了。