本文翻譯自國外論壇 medium，原文地址：https://medium.com/@interviewready/data-replication-in-distributed-system-87f7d265ff28

什么是數(shù)據(jù)復制？

數(shù)據(jù)復制是指將數(shù)據(jù)復制到一個或多個數(shù)據(jù)容器以確?？捎眯缘倪^程。復制的數(shù)據(jù)通常存儲在不同的數(shù)據(jù)庫實例中，即使一個實例發(fā)生故障，我們也可以從其他實例獲取數(shù)據(jù)。

一種流行數(shù)據(jù)復制的實現(xiàn)架構是主從架構。

“

推薦博主開源的 H5 商城項目waynboot-mall，這是一套全部開源的微商城項目，包含三個項目：運營后臺、H5 商城前臺和服務端接口。實現(xiàn)了商城所需的首頁展示、商品分類、商品詳情、商品 sku、分詞搜索、購物車、結算下單、支付寶/微信支付、收單評論以及完善的后臺管理等一系列功能。技術上基于最新得 Springboot3.0、jdk17，整合了 MySql、Redis、RabbitMQ、ElasticSearch 等常用中間件。分模塊設計、簡潔易維護，歡迎大家點個 star、關注博主。

github 地址：https://github.com/wayn111/waynboot-mall

”

主從架構

為了理解這個架構，我們舉一個例子。

• 我們有四個客戶端，每個客戶端都連接到一個負載均衡器。
• 然后負載均衡器將請求分發(fā)到三個應用程序服務器。
• 每臺服務器連接到一個數(shù)據(jù)庫實例。

你能注意到這里有什么問題嗎？

我們的數(shù)據(jù)庫存在單點故障。如果它崩潰了，我們的整個系統(tǒng)就會停止工作。

為了避免這種單點故障，我們可以使用另一個數(shù)據(jù)庫（最好是不同的數(shù)據(jù)庫實例）來存儲原始數(shù)據(jù)的副本（一般我們成為從庫）?，F(xiàn)在如果原始數(shù)據(jù)庫（主庫）崩潰，我們可以將請求轉到從庫。

但是我們如何保持從庫與主庫同步呢？這有兩種方法。

同步復制數(shù)據(jù)

• 在這種方法中，數(shù)據(jù)同時寫入主庫和從庫
• 數(shù)據(jù)始終一致。即數(shù)據(jù)如果寫入主庫，它也會寫入從庫
• 數(shù)據(jù)庫負載較高

異步復制數(shù)據(jù)

• 在這種方法中，首先將數(shù)據(jù)寫入主庫，并定期將更新寫入從庫
• 由于復制以固定間隔進行，因此存在數(shù)據(jù)丟失和不一致的可能性
• 數(shù)據(jù)庫負載相對較低

這里我們的一般定義是收到寫請求的主庫數(shù)據(jù)庫是 master）。從庫被稱為 slaves。

主從架構

如上圖我們的主站也就是 Server2 維護事務日志。他會更新從站中（Server1）的數(shù)據(jù)，它發(fā)送命令，然后從站以相同的順序執(zhí)行這些命令。

如果服務器向從站發(fā)送寫入請求會發(fā)生什么？

有兩種方法可以處理這種情況

• 不允許對從站的寫請求，從站無法寫入數(shù)據(jù)庫，它只能去讀從庫數(shù)據(jù)。
• 允許從站寫入數(shù)據(jù)。我們將允許從站寫入數(shù)據(jù)。然后從站將更改復制到主站。在這種情況下，從站就接替了主站的角色。所以不再是主從架構而是主主架構

主主架構的問題

網(wǎng)絡故障可能會導致主主架構中的數(shù)據(jù)不一致。

讓我們用一個例子來理解這一點，假設我們有兩個數(shù)據(jù)庫實例 A 和 B。

• 兩人都是 master。
• 它們之間的路由器出現(xiàn)故障。所以 A 認為 B 離線，B 認為 A 離線。
• 他們有一個數(shù)據(jù)項 X，其值最初為 100。

現(xiàn)在用戶發(fā)送以下請求，

• X 減去 20，該請求被路由到 A，此時 A 中 X 的值為 80。
• X 減去 80，這個請求被路由到 B（因為都是 master，所以寫請求可以路由到任何數(shù)據(jù)庫）?，F(xiàn)在 B 中 X 的值為 20。

由于存在通信故障，A 和 B 無法同步，它們具有不同的數(shù)據(jù)值，因此不一致。

• 
  
• 現(xiàn)在，如果用戶發(fā)出讀請求，他/她將獲得不同的值，具體取決于他/她將連接到的數(shù)據(jù)庫。

這個問題被稱為裂腦問題。

解決裂腦問題

解決裂腦問題

我們可以通過添加第三個節(jié)點（數(shù)據(jù)庫實例）來解決裂腦問題。

這里我們假設一個節(jié)點崩潰以及其他兩個節(jié)點之間的路由器崩潰的可能性極小。

讓我們考慮三個數(shù)據(jù)庫實例 A、B 和 C。

• 如果 C 崩潰，A 和 B 是主庫并且它們是同步的。所以他們處于一致的狀態(tài)。當 C 在線時，他們可以讀取 A 或 B 的內容。
• 如果 A 和 B 之間出現(xiàn)通信故障
• 當 A 收到寫入請求時，它將其狀態(tài)傳播到 C。最初狀態(tài)為 S0，然后轉移到 Sx。所以現(xiàn)在 A 和 C 都有 Sx。
• 當 B 收到寫入請求時，它將其狀態(tài)從 S0 移至 Sy。它嘗試將其狀態(tài)傳播到 C，但失敗，因為 B 的先前狀態(tài)不等于 C?，F(xiàn)在 B 中止寫入請求并將其狀態(tài)更新為 Sx。現(xiàn)在 B 可以接受寫入請求并將更改傳播到 C。

這稱為分布式共識。多個節(jié)點就特定值達成一致。在這種情況下，A、B 和 C 在最終狀態(tài)上達成一致。

最后

感謝您的閱讀，希望本文能對你理解分布式架構中的數(shù)據(jù)復制有所幫助。