MySQL 主從同步是 MySQL 集群方案中的一種，也是實(shí)現(xiàn)難度最低的一種。

然而，現(xiàn)在的面試都不問 MySQL 主從同步原理了，而是開始問主從同步怎么保證數(shù)據(jù)一致性問題了。

所以，今天就給大家安排上了。

1.什么是數(shù)據(jù)一致性？

數(shù)據(jù)一致性是指在一個系統(tǒng)中，數(shù)據(jù)在不同的部分、不同的時間點(diǎn)，以及不同的操作之間保持一致的狀態(tài)。

數(shù)據(jù)一致性通常體現(xiàn)在以下幾點(diǎn)：

• 數(shù)據(jù)一致性：確保數(shù)據(jù)的完整性意味著數(shù)據(jù)在存儲和傳輸過程中沒有被損壞或丟失。這包括數(shù)據(jù)的準(zhǔn)確性、完整性和有效性。例如，在一個電商系統(tǒng)中，商品的庫存數(shù)量應(yīng)該是準(zhǔn)確的。如果一個用戶購買了一件商品，庫存數(shù)量應(yīng)該相應(yīng)地減少。如果庫存數(shù)量顯示不正確，就會導(dǎo)致數(shù)據(jù)不一致。
• 事務(wù)一致性：在數(shù)據(jù)庫系統(tǒng)中，事務(wù)是一組操作的集合，這些操作要么全部成功執(zhí)行，要么全部回滾。事務(wù)一致性確保在一個事務(wù)中對數(shù)據(jù)的修改在事務(wù)提交后對所有用戶都是可見的，并且如果事務(wù)失敗，數(shù)據(jù)將恢復(fù)到事務(wù)開始之前的狀態(tài)。例如，在一個在線預(yù)訂系統(tǒng)中，用戶預(yù)訂了一個酒店房間，系統(tǒng)應(yīng)該確保這個房間在預(yù)訂期間不能被其他用戶預(yù)訂。如果出現(xiàn)多個用戶同時預(yù)訂同一個房間的情況，就會導(dǎo)致數(shù)據(jù)不一致。
• 多副本一致性：在分布式系統(tǒng)中，數(shù)據(jù)通常會存儲在多個副本中，以提高系統(tǒng)的可用性和性能。多副本一致性確保不同副本之間的數(shù)據(jù)保持一致。例如，在一個云存儲服務(wù)中，用戶上傳了一個文件，這個文件會被存儲在多個數(shù)據(jù)中心的服務(wù)器上。如果用戶對文件進(jìn)行了修改，云存儲服務(wù)應(yīng)該確保所有副本都被更新，以保證用戶在任何地方訪問文件時都能看到最新的版本。
• 時間一致性：時間一致性要求數(shù)據(jù)在不同的時間點(diǎn)上保持一致，這包括數(shù)據(jù)的時效性和順序性。例如，在一個股票交易系統(tǒng)中，交易訂單的處理應(yīng)該按照時間順序進(jìn)行。如果訂單的處理順序出現(xiàn)錯誤，就會導(dǎo)致交易數(shù)據(jù)不一致。

PS：我們本文主要討論的是多副本在同一時間上的數(shù)據(jù)一致性問題。

2.主從復(fù)制

MySQL 主從復(fù)制是一種將 MySQL 主數(shù)據(jù)庫的數(shù)據(jù)，同步到其他的數(shù)據(jù)庫的一種機(jī)制，從而實(shí)現(xiàn)數(shù)據(jù)的冗余備份和負(fù)載均衡，平行擴(kuò)展了數(shù)據(jù)庫的查詢能力。

主從數(shù)據(jù)庫基本概念：

• 主數(shù)據(jù)庫（Master）：主數(shù)據(jù)庫是數(shù)據(jù)的主要來源，負(fù)責(zé)接收和處理所有的寫操作（INSERT、UPDATE、DELETE 等）。主數(shù)據(jù)庫將所有的寫操作記錄到二進(jìn)制日志（Binary Log）中，這些日志記錄了數(shù)據(jù)庫的變更歷史。
• 從數(shù)據(jù)庫（Slave）：從數(shù)據(jù)庫通過復(fù)制主數(shù)據(jù)庫的二進(jìn)制日志來同步數(shù)據(jù)。從數(shù)據(jù)庫可以處理讀操作（SELECT），從而分擔(dān)主數(shù)據(jù)庫的負(fù)載。

MySQL 主從復(fù)制流程如下：

圖片

它的主要執(zhí)行流程如下：

• 主數(shù)據(jù)庫接收到一個寫操作（如 INSERT、UPDATE、DELETE）時，會將這個操作記錄到二進(jìn)制日志（Binary Log）中，將數(shù)據(jù)修改的操作按順序記錄下來。
• 從數(shù)據(jù)庫 IO 線程會自動連接主服務(wù)，從二進(jìn)制中讀取同步數(shù)據(jù)，記錄到中繼日志（Relay Log）中。
• 從數(shù)據(jù)庫的 SQL 線程會定期從中繼日志中獲取同步數(shù)據(jù)，寫入到從數(shù)據(jù)庫中。

3.MySQL主從同步類型

MySQL 主從同步方式有以下三種：

圖片

3.1 異步復(fù)制

異步復(fù)制默認(rèn)的主從同步復(fù)制模式，在這種模式下，主服務(wù)器提交事務(wù)后立即返回客戶端，無需等待從服務(wù)器確認(rèn)是否成功接收并應(yīng)用了事務(wù)，從服務(wù)器會在后臺獨(dú)立地接收并應(yīng)用事務(wù)日志。

異步同步流程如下（紅色部分為主要執(zhí)行流程）：

圖片

優(yōu)點(diǎn)

• 性能：異步復(fù)制模式下，主服務(wù)器的寫操作不會因?yàn)榈却龔姆?wù)器的確認(rèn)而被阻塞，因此可以提供更高的寫入吞吐量。
• 簡單：配置和管理相對簡單。
• 成本：不需要額外的硬件資源支持，因?yàn)椴恍枰咚俚木W(wǎng)絡(luò)連接來保證同步。

缺點(diǎn)

數(shù)據(jù)丟失問題：在主服務(wù)器故障的情況下，可能存在數(shù)據(jù)未完全同步到從服務(wù)器的情況，導(dǎo)致數(shù)據(jù)丟失或不一致。

3.2 同步復(fù)制

同步復(fù)制是一種最為嚴(yán)格的復(fù)制模式，它要求主服務(wù)器在提交一個事務(wù)之前，必須等待所有從服務(wù)器確認(rèn)確認(rèn)接收到并應(yīng)用了事務(wù)之后，主服務(wù)器才會向客戶端返回事務(wù)提交成功的消息。

同步復(fù)制執(zhí)行流程如下：

圖片

優(yōu)點(diǎn)

• 數(shù)據(jù)一致性：提供了更高的數(shù)據(jù)一致性保障，因?yàn)橹鞣?wù)器必須等待從服務(wù)器確認(rèn)才能完成事務(wù)提交。
• 容錯性：即使主服務(wù)器發(fā)生故障，至少有一個從服務(wù)器擁有最新的數(shù)據(jù)，從而減少了數(shù)據(jù)丟失的風(fēng)險。

缺點(diǎn)

• 性能開銷大：主庫需要等待所有從庫的響應(yīng)，這會導(dǎo)致事務(wù)提交的延遲增加，尤其是在從庫數(shù)量較多或網(wǎng)絡(luò)狀況不佳時，性能下降明顯。
• 單點(diǎn)故障風(fēng)險：如果一個從庫出現(xiàn)故障，可能會導(dǎo)致整個系統(tǒng)的阻塞，因?yàn)橹鲙煨枰却袕膸斓拇_認(rèn)。

3.3 半同步復(fù)制

半同步復(fù)制是一種折衷方案，它結(jié)合了異步復(fù)制的高性能和同步復(fù)制的高可靠性。在半同步復(fù)制模式下，主服務(wù)器在提交一個事務(wù)之前，需要等待至少一個從服務(wù)器確認(rèn)接收到該事務(wù)的日志，但不需要等待從服務(wù)器完成應(yīng)用。

半同步執(zhí)行流程如下：

圖片

優(yōu)點(diǎn)

• 數(shù)據(jù)一致性較好：相比異步復(fù)制，提供了更好的數(shù)據(jù)一致性保障。
• 性能影響較小：相比同步復(fù)制，半同步復(fù)制的性能開銷較小，因?yàn)橹恍枰却粋€從庫的確認(rèn)。
• 靈活性較高：可以根據(jù)需要調(diào)整等待的從服務(wù)器數(shù)量，以適應(yīng)不同的性能和可靠性需求。

缺點(diǎn)

• 性能波動風(fēng)險：在網(wǎng)絡(luò)延遲較高或從庫負(fù)載較大的情況下，可能會導(dǎo)致主庫等待從庫確認(rèn)的時間過長，從而影響性能。
• 配置復(fù)雜：相比異步復(fù)制，配置和管理稍微復(fù)雜一些。

4.小結(jié)

因此，想要保證數(shù)據(jù)完全一致性需要使用同步復(fù)制，但這會犧牲一定的性能；因此在生產(chǎn)環(huán)境我們可以使用半同步保證較好的數(shù)據(jù)一致性即可；而默認(rèn)的異步方式實(shí)現(xiàn)最簡單、性能最好，但可能存在數(shù)據(jù)不一致的風(fēng)險，雖然發(fā)生的概率極低（生產(chǎn)環(huán)境也可以使用）。