大家好，Mysql 是大家最常用的數(shù)據(jù)庫，下面為大家?guī)?mysql 主從同步知識(shí)點(diǎn)的分享，以便鞏固 mysql 基礎(chǔ)知識(shí)，如有錯(cuò)誤，還請(qǐng)各位大佬們指正。

一、MySql 主從同步概述

MySQL 主從同步，即 MySQL Replication，可以實(shí)現(xiàn)將數(shù)據(jù)從一臺(tái)數(shù)據(jù)庫服務(wù)器同步到多臺(tái)數(shù)據(jù)庫服務(wù)器。MySQL 數(shù)據(jù)庫自帶主從同步功能，經(jīng)過配置，可以實(shí)現(xiàn)基于庫、表結(jié)構(gòu)的多種方案的主從同步。

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

隨著業(yè)務(wù)量的不斷增長，數(shù)據(jù)庫的壓力會(huì)不斷變大，緩存的頻繁變更也強(qiáng)依賴于數(shù)據(jù)的查詢結(jié)果，導(dǎo)致數(shù)據(jù)查詢效率低，負(fù)載很高，連接過多等問題。對(duì)于電商場(chǎng)景來說，往往存在很多典型的讀多寫少場(chǎng)景，我們可以對(duì) MySQL 做主從架構(gòu)并且進(jìn)行讀寫分離，讓主服務(wù)器（Master）處理寫請(qǐng)求，從服務(wù)器（Slave）處理讀請(qǐng)求，這樣可以進(jìn)一步提升數(shù)據(jù)庫的并發(fā)處理能力。如下圖：

上圖中，可以看到，我們?cè)黾恿?2 個(gè)從庫，這 2 個(gè)從庫可以一起抗下大量的讀請(qǐng)求，分擔(dān)主庫壓力。從庫會(huì)通過主從復(fù)制，從主庫中不斷的同步數(shù)據(jù)，以此來保證從庫的數(shù)據(jù)和主庫數(shù)據(jù)的一致。

接下來，我們看看主從同步有哪些作用，以及主從同步具體是怎么實(shí)現(xiàn)的。

二、主從同步的作用

一般來說，不是所有的系統(tǒng)都需要對(duì)數(shù)據(jù)庫進(jìn)行主從架構(gòu)的設(shè)計(jì)，因?yàn)榧軜?gòu)本身是有一定成本的，如果我們的目的在于提升數(shù)據(jù)庫高并發(fā)訪問的效率，那么我們首先應(yīng)該優(yōu)化 SQL 語句及索引，充分發(fā)揮數(shù)據(jù)庫的最大性能；其次是采用緩存的策略，如使用 Redis、Magodb 等緩存工具，通過其高性能的優(yōu)勢(shì)把數(shù)據(jù)保存在內(nèi)存數(shù)據(jù)庫中，提升讀取的效率，最后才是對(duì)數(shù)據(jù)庫采用主從架構(gòu)，進(jìn)行讀寫分離。系統(tǒng)的使用和維護(hù)成本是根據(jù)架構(gòu)的升級(jí)逐漸升高的。

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

1. 讀寫分離

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

2. 數(shù)據(jù)備份

主從同步也相當(dāng)于是一種數(shù)據(jù)熱備份機(jī)制，在主庫正常運(yùn)行下進(jìn)行備份，不影響提供數(shù)據(jù)服務(wù)。

3. 高可用性

數(shù)據(jù)備份實(shí)際就是一種冗余的機(jī)制，通過這種冗余的方式可以換取數(shù)據(jù)庫的高可用性，當(dāng)服務(wù)器出現(xiàn)故障、宕機(jī)等無可用的情況下，可以迅速進(jìn)行故障切換，讓從庫充當(dāng)主庫，保障服務(wù)正常運(yùn)行。大家可以了解下電商系統(tǒng)數(shù)據(jù)庫高可用 SLA 指標(biāo)。

三、主從同步的原理

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

在主從復(fù)制的過程中，會(huì)基于三個(gè)線程來操作，一個(gè)是 binlog dump 線程，位于 master 節(jié)點(diǎn)上，另外兩個(gè)線程分別是 I/O 線程和 SQL 線程，它們都分別位于 slave 節(jié)點(diǎn)上，如下圖：

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

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

主從同步的數(shù)據(jù)內(nèi)容其實(shí)是二進(jìn)制日志（Binlog），它雖然叫二進(jìn)制日志，實(shí)際上存儲(chǔ)的是一個(gè)又一個(gè)的事件（Event），這些事件分別對(duì)應(yīng)著數(shù)據(jù)庫的更新操作，比如 INSERT、UPDATE、DELETE 等。

另外我們還需要注意的是，不是所有版本的 MySQL 都默認(rèn)開啟了服務(wù)器的二進(jìn)制日志，在進(jìn)行主從同步的時(shí)候，我們需要先檢查服務(wù)器是否已經(jīng)開啟了二進(jìn)制日志。

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

四、如何解決主從同步的數(shù)據(jù)一致性問題

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

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

1. 全同步復(fù)制

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

2. 異步復(fù)制

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

因?yàn)橹鲙熘还茏约簣?zhí)行完事務(wù)，就可以將處理結(jié)果返回給客戶端，而不用關(guān)心從庫是否執(zhí)行完事務(wù)，這就可能導(dǎo)致短暫的主從數(shù)據(jù)不一致的問題了，比如剛在主庫插入的新數(shù)據(jù)，如果馬上在從庫查詢，就可能查詢不到。

而且，當(dāng)主庫提交事物后，如果宕機(jī)掛掉了，此時(shí)可能 binlog 還沒來得及同步給從庫，這時(shí)候如果為了恢復(fù)故障切換主從節(jié)點(diǎn)的話，就會(huì)出現(xiàn)數(shù)據(jù)丟失的問題，所以異步復(fù)制雖然性能高，但數(shù)據(jù)一致性上是最弱的。

mysql 主從復(fù)制，默認(rèn)采用的就是異步復(fù)制這種復(fù)制策略。

?

3. 半同步復(fù)制

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

在 MySQL5.7 版本中還增加了一個(gè) rpl_semi_sync_master_wait_for_slave_count 參數(shù)，我們可以對(duì)需要響應(yīng)的從庫數(shù)量進(jìn)行設(shè)置，默認(rèn)為 1，也就是說只要有一個(gè)從庫進(jìn)行了響應(yīng)，就可以返回給客戶端。如果將這個(gè)參數(shù)調(diào)大，可以提升數(shù)據(jù)一致性的強(qiáng)度，但也會(huì)增加主庫等待從庫響應(yīng)的時(shí)間。

但是，半同步復(fù)制也存在以下幾個(gè)問題：

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

當(dāng)主庫成功提交事物并處于等待從庫確認(rèn)的過程中，這個(gè)時(shí)候，從庫都還沒來得及返回處理結(jié)果給客戶端，但因?yàn)橹鲙齑鎯?chǔ)引擎內(nèi)部已經(jīng)提交事務(wù)了，所以，其他客戶端是可以到從主庫中讀到數(shù)據(jù)的。

但是，如果下一秒主庫突然掛了，此時(shí)正好下一次請(qǐng)求過來，因?yàn)橹鲙鞉炝耍椭荒馨颜?qǐng)求切換到從庫中，因?yàn)閺膸爝€沒從主庫同步完數(shù)據(jù)，所以，從庫中當(dāng)然就讀不到這條數(shù)據(jù)了，和上一秒讀取數(shù)據(jù)的結(jié)果對(duì)比，就造成了幻讀的現(xiàn)象了。

4. 增強(qiáng)半同步復(fù)制

增強(qiáng)半同步復(fù)制，是 mysql 5.7.2 后的版本對(duì)半同步復(fù)制做的一個(gè)改進(jìn)，原理上幾乎是一樣的，主要是解決幻讀的問題。

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

?

五、總結(jié)

通過上述內(nèi)容，我們了解了 Mysql 數(shù)據(jù)庫的主從同步，如果你的目標(biāo)僅是數(shù)據(jù)庫的高并發(fā)，那么可以先從 SQL 優(yōu)化，索引以及 Redis 緩存數(shù)據(jù)等這些方面來考慮優(yōu)化，然后再考慮是否采用主從架構(gòu)的方式。

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

自己編寫程序的好處就在于比較自主，我們可以自己判斷哪些查詢?cè)趶膸焐蟻韴?zhí)行，針對(duì)實(shí)時(shí)性要求高的需求，我們還可以考慮哪些查詢可以在主庫上執(zhí)行。同時(shí)程序直接連接數(shù)據(jù)庫，減少了中間件層，可以減少一些性能損耗。

而采用中間件的方法有很明顯的優(yōu)勢(shì)，功能強(qiáng)大，使用簡單。但因?yàn)樵诳蛻舳撕蛿?shù)據(jù)庫之間增加了中間件層會(huì)有一些性能損耗，同時(shí)商業(yè)中間件價(jià)格較高，有一定學(xué)習(xí)成本。另外，我們也可以考慮采用一些優(yōu)秀的開源工具，比如 MaxScale。它是 MariaDB 開發(fā)的 MySQL 數(shù)據(jù)中間件。比如在下圖中，使用 MaxScale 作為數(shù)據(jù)庫的代理，通過路由轉(zhuǎn)發(fā)完成了讀寫分離。同時(shí)我們也可以使用 MHA 工具作為強(qiáng)一致的主從切換工具，從而完成 MySQL 的高可用架構(gòu)。?