大家好，Mysql 是大家最常用的數據庫，下面為大家帶來 mysql 主從同步知識點的分享，以便鞏固 mysql 基礎知識，如有錯誤，還請各位大佬們指正。

一、MySql 主從同步概述

MySQL 主從同步，即 MySQL Replication，可以實現將數據從一臺數據庫服務器同步到多臺數據庫服務器。MySQL 數據庫自帶主從同步功能，經過配置，可以實現基于庫、表結構的多種方案的主從同步。

Redis 是一種高性能的內存數據庫，但不是今天的主角；MySQL 是基于磁盤文件的關系型數據庫，相比于 Redis 來說，讀取速度會慢一些，但是功能強大，可以用于存儲持久化的數據。在實際工作中，我們常將 Redis 作為緩存與 MySQL 配合來使用，當有數據訪問請求的時候，首先會從緩存中進行查找，如果存在就直接取出，如果不存在再訪問數據庫，這樣就提升了讀取的效率，也減少了后端數據庫的訪問壓力。使用 Redis 這種緩存架構是高并發架構中非常重要的一環。

隨著業務量的不斷增長，數據庫的壓力會不斷變大，緩存的頻繁變更也強依賴于數據的查詢結果，導致數據查詢效率低，負載很高，連接過多等問題。對于電商場景來說，往往存在很多典型的讀多寫少場景，我們可以對 MySQL 做主從架構并且進行讀寫分離，讓主服務器（Master）處理寫請求，從服務器（Slave）處理讀請求，這樣可以進一步提升數據庫的并發處理能力。如下圖：

上圖中，可以看到，我們增加了 2 個從庫，這 2 個從庫可以一起抗下大量的讀請求，分擔主庫壓力。從庫會通過主從復制，從主庫中不斷的同步數據，以此來保證從庫的數據和主庫數據的一致。

接下來，我們看看主從同步有哪些作用，以及主從同步具體是怎么實現的。

二、主從同步的作用

一般來說，不是所有的系統都需要對數據庫進行主從架構的設計，因為架構本身是有一定成本的，如果我們的目的在于提升數據庫高并發訪問的效率，那么我們首先應該優化 SQL 語句及索引，充分發揮數據庫的最大性能；其次是采用緩存的策略，如使用 Redis、Magodb 等緩存工具，通過其高性能的優勢把數據保存在內存數據庫中，提升讀取的效率，最后才是對數據庫采用主從架構，進行讀寫分離。系統的使用和維護成本是根據架構的升級逐漸升高的。

言歸正傳，主從同步不僅可以提升數據庫的吞吐量，還有以下三個方面的作用：

1. 讀寫分離

我們可以通過主從復制的方式來同步數據，然后通過讀寫分離提升數據庫的并發處理能力。簡單來說就是我們的數據被放在了多個數據庫中，其中一個是 Master 主庫，其余的是 Slave 從庫。當主庫數據變化時，會自動將數據同步到從庫中，而我們程序可以從從庫讀取數據，也就是采用讀寫分離的方式。電商的應用往往是 “讀多寫少”，采用讀寫分離就實現了更高的并發訪問。原本所有的讀寫壓力都由一臺服務器承擔，現在有多個服務器共同處理讀請求，減少了對主庫的壓力。另外還可以對從服務器進行負載均衡，讓不同的讀請求按照策略均勻的分配到不同的從服務器中，讓讀取更加順暢。讀取順暢的另一個原因，就是減少了鎖表的影響，比如我們讓主庫負責寫，當主庫出現寫鎖的時候，不會影響到從庫的查詢操作。

2. 數據備份

主從同步也相當于是一種數據熱備份機制，在主庫正常運行下進行備份，不影響提供數據服務。

3. 高可用性

數據備份實際就是一種冗余的機制，通過這種冗余的方式可以換取數據庫的高可用性，當服務器出現故障、宕機等無可用的情況下，可以迅速進行故障切換，讓從庫充當主庫，保障服務正常運行。大家可以了解下電商系統數據庫高可用 SLA 指標。

三、主從同步的原理

說到主從同步的原理，我們就需要了解在數據庫中的一個重要日志文件，就是 Binlog 二進制文件，它記錄了對數據庫進行更新的事件，事實上主從同步的原理就是基于 Binlog 進行數據同步的。

在主從復制的過程中，會基于三個線程來操作，一個是 binlog dump 線程，位于 master 節點上，另外兩個線程分別是 I/O 線程和 SQL 線程，它們都分別位于 slave 節點上，如下圖：

結合以上圖片，我們一起來了解主從復制的核心流程：

• 當 master 節點接收到一個寫請求時，這個寫請求可能是增刪改操作，此時會把寫請求的更新操作都記錄到 binlog 日志中。
• master 節點會把數據復制給 slave 節點，如圖中的 slave01 節點和 slave02 節點，這個過程，首先得要每個 slave 節點連接到 master 節點上，當 slave 節點連接到 master 節點上時，master 節點會為每一個 slave 節點分別創建一個 binlog dump 線程，用于向各個 slave 節點發送 binlog 日志。
• binlog dump 線程會讀取 master 節點上的 binlog 日志，然后將 binlog 日志發送給 slave 節點上的 I/O 線程。當主庫讀取事件的時候，會在 Binglog 上加鎖，讀取完成之后，再將鎖釋放掉。
• slave 節點上的 I/O 線程接收到 binlog 日志后，會將 binlog 日志先寫入到本地的 relaylog 中，relaylog 中就保存了 binlog 日志。
• slave 節點上的 SQL 線程，會來讀取 relaylog 中的 binlog 日志，將其解析成具體的增刪改操作，把這些在 master 節點上進行過的操作，重新在 slave 節點上也重做一遍，達到數據還原的效果，這樣就可以保證 master 節點和 slave 節點的數據一致性了。

主從同步的數據內容其實是二進制日志（Binlog），它雖然叫二進制日志，實際上存儲的是一個又一個的事件（Event），這些事件分別對應著數據庫的更新操作，比如 INSERT、UPDATE、DELETE 等。

另外我們還需要注意的是，不是所有版本的 MySQL 都默認開啟了服務器的二進制日志，在進行主從同步的時候，我們需要先檢查服務器是否已經開啟了二進制日志。

二進制日志，它是一個文件，在進行網絡傳輸的過程中就一定會存在一些延遲，比如 200ms，這樣就可能造成用戶在從庫上讀取的數據不是最新的數據，也就會造成主從同步中的數據不一致的情況發生。比如我們對一條記錄進行更新，這個操作是在主庫上完成的，而在很短的時間內，比如 100ms，又對同一個記錄進行讀取，這時候從庫還沒有完成數據的同步，那么，我們通過從庫讀取到的數據就是一條舊的數據。這種情況下該怎么辦呢？

四、如何解決主從同步的數據一致性問題

可以想象下，如果我們想要操作的數據都存儲在同一個數據庫中，那么對數據進行更新的時候，可以對記錄進行加寫鎖，這樣在讀取的時候就不會發生數據不一致的情況了。但這時從庫的作用就是備份數據，沒有做到讀寫分離，分擔主庫的壓力。

因此我們還需要想辦法，在進行讀寫分離的時候，解決主從同步中數據不一致的問題，也就是解決主從之間數據復制方式的問題，如果按照數據一致性從弱到強來進行劃分，有以下三種復制方式。

1. 全同步復制

首先，全同步復制，就是當主庫執行完一個事務之后，要求所有的從庫也都必須執行完該事務，才可以返回處理結果給客戶端；因此，雖然全同步復制數據一致性得到保證了，但是主庫完成一個事物需要等待所有從庫也完成，性能就比較低了。如下圖：

2. 異步復制

而異步復制，就是當主庫提交事物后，會通知 binlog dump 線程發送 binlog 日志給從庫，一旦 binlog dump 線程將 binlog 日志發送給從庫之后，不需要等到從庫也同步完成事務，主庫就會將處理結果返回給客戶端。

因為主庫只管自己執行完事務，就可以將處理結果返回給客戶端，而不用關心從庫是否執行完事務，這就可能導致短暫的主從數據不一致的問題了，比如剛在主庫插入的新數據，如果馬上在從庫查詢，就可能查詢不到。

而且，當主庫提交事物后，如果宕機掛掉了，此時可能 binlog 還沒來得及同步給從庫，這時候如果為了恢復故障切換主從節點的話，就會出現數據丟失的問題，所以異步復制雖然性能高，但數據一致性上是最弱的。

mysql 主從復制，默認采用的就是異步復制這種復制策略。

?

3. 半同步復制

MySQL5.5 版本之后開始支持半同步復制的方式。原理是在客戶端提交 COMMIT 之后不直接將結果返回給客戶端，而是等待至少有一個從庫收到了 Binlog，并且寫入到中繼日志中，再返回給客戶端。這樣做的好處就是提高了數據的一致性，當然相比于異步復制來說，至少多增加了一個網絡連接的延遲，降低了主庫寫的效率。

在 MySQL5.7 版本中還增加了一個 rpl_semi_sync_master_wait_for_slave_count 參數，我們可以對需要響應的從庫數量進行設置，默認為 1，也就是說只要有一個從庫進行了響應，就可以返回給客戶端。如果將這個參數調大，可以提升數據一致性的強度，但也會增加主庫等待從庫響應的時間。

但是，半同步復制也存在以下幾個問題：

• 半同步復制的性能，相比異步復制而言有所下降，相比于異步復制是不需要等待任何從庫是否接收到數據的響應，而半同步復制則需要等待至少一個從庫確認接收到 binlog 日志的響應，性能上是損耗更大的。
• 主庫等待從庫響應的最大時長是可以配置的，如果超過了配置的時間，半同步復制就會變成異步復制，那么，異步復制的問題同樣也就會出現了。
• 在 MySQL 5.7.2 之前的版本中，半同步復制存在著幻讀問題的。

當主庫成功提交事物并處于等待從庫確認的過程中，這個時候，從庫都還沒來得及返回處理結果給客戶端，但因為主庫存儲引擎內部已經提交事務了，所以，其他客戶端是可以到從主庫中讀到數據的。

但是，如果下一秒主庫突然掛了，此時正好下一次請求過來，因為主庫掛了，就只能把請求切換到從庫中，因為從庫還沒從主庫同步完數據，所以，從庫中當然就讀不到這條數據了，和上一秒讀取數據的結果對比，就造成了幻讀的現象了。

4. 增強半同步復制

增強半同步復制，是 mysql 5.7.2 后的版本對半同步復制做的一個改進，原理上幾乎是一樣的，主要是解決幻讀的問題。

主庫配置了參數 rpl_semi_sync_master_wait_point = AFTER_SYNC 后，主庫在存儲引擎提交事務前，必須先收到從庫數據同步完成的確認信息后，才能提交事務，以此來解決幻讀問題。參考下圖：

?

五、總結

通過上述內容，我們了解了 Mysql 數據庫的主從同步，如果你的目標僅是數據庫的高并發，那么可以先從 SQL 優化，索引以及 Redis 緩存數據等這些方面來考慮優化，然后再考慮是否采用主從架構的方式。

在主從架構的配置中，如果想要采取讀寫分離的策略，我們可以自己編寫程序，也可以通過第三方的中間件來實現。

自己編寫程序的好處就在于比較自主，我們可以自己判斷哪些查詢在從庫上來執行，針對實時性要求高的需求，我們還可以考慮哪些查詢可以在主庫上執行。同時程序直接連接數據庫，減少了中間件層，可以減少一些性能損耗。

而采用中間件的方法有很明顯的優勢，功能強大，使用簡單。但因為在客戶端和數據庫之間增加了中間件層會有一些性能損耗，同時商業中間件價格較高，有一定學習成本。另外，我們也可以考慮采用一些優秀的開源工具，比如 MaxScale。它是 MariaDB 開發的 MySQL 數據中間件。比如在下圖中，使用 MaxScale 作為數據庫的代理，通過路由轉發完成了讀寫分離。同時我們也可以使用 MHA 工具作為強一致的主從切換工具，從而完成 MySQL 的高可用架構。?