作者：京東保險 王奕龍

1. 為什么需要復制

我們可以考慮如下問題：

當數據量、讀取或寫入負載已經超過了當前服務器的處理能力，如何實現負載均衡？

希望在單臺服務器出現故障時仍能繼續工作，這該如何實現？

當服務的用戶遍布全球，并希望他們訪問服務時不會有較大的延遲，怎么才能統一用戶的交互體驗？

這些問題其實都能通過 “復制” 來解決：復制，即在不同的節點上保存相同的副本，提供數據冗余。如果一些節點不可用，剩余的節點仍然可以提供數據服務，這些節點可能部署在不同的地理位置，以此來改善系統性能，針對以上三個問題的解決方案如下：

采用無共享架構（shared-nothing architecture），進行 橫向擴展，將數據分散到多臺服務器上，進行有效的 負載均衡，提高服務的 伸縮性

部署多臺服務器，在一臺宕機時，其他服務器能隨時接管，實現服務的 高可用

在多地理位置上部署服務，使用戶能就近訪問，避免產生較大的延遲，統一用戶體驗

2. 單主復制

單主節點復制 是工作中最常見的復制解決方案。存儲了數據庫拷貝的每個節點被稱為 副本（replica），每次向數據庫的寫入操作都需要傳播到所有副本上，否則副本數據就會不一致，它的工作原理如下：

其中一個副本被指定為 領導者，也稱為主庫，當客戶端要向數據庫寫入時，它必須將該請求發送給領導者

其他副本被稱為 追隨者，也被稱為 從庫 或 只讀副本，每當領導者將數據寫入本地存儲時，它會將數據變更以 復制日志 或 變更流 的形式推送給所有的追隨者，并且追隨者按照與領導者 相同的處理順序 來進行寫入

2.1 節點間的數據同步

數據的同步分 同步復制 和 異步復制，同步復制的好處是從庫能夠保證與主庫有一致的數據，當主庫失效時，這些數據能夠在從庫上找到，但是它的缺點也很明顯：主庫需要等待從庫的數據同步結果，如果同步從庫沒有響應，主庫就無法再處理新的寫入操作，而是進入阻塞狀態。

在 讀多寫少 的場景下，我們通常會增加從節點的數量來對讀請求進行負載均衡，但是如果此時所有從庫都是同步復制是不實際的且不可靠的，因為單個節點的故障或網絡中斷都會影響數據的寫入。

事實上數據庫啟用同步復制時，通常表示有一個從庫是同步復制，其他從庫是異步復制，當同步從庫失效時，異步復制的副本會改為同步復制，這保證了至少有兩個節點擁有最新的數據副本，這種配置也被成為 半同步。

而通常情況下，基于領導者的復制都配置為 完全異步。如下圖所示，用戶1234修改picture_url 信息時，從主庫同步到從庫是存在延遲的。

這意味著如果此時主庫失效而尚未復制給從庫的數據會丟失，導致已經向客戶端請求確認成功也不能保證寫入是持久的，而且如果在主節點寫入數據后，立即向 Follower 2 讀取數據，則會讀取到舊數據，給用戶的感覺就像是剛才的寫入丟失了一樣，這對應了 讀己之寫一致性 問題，我們在后文會做具體解釋。

但是實際生產情況下都基于異步復制，說明強一致性并不是必要的保證，而對保證系統 吞吐量 的需求更高。因為在這種機制下，即使從庫已經遠遠落后，主庫也不必等待從庫寫入完成就可以返回數據寫入成功。之后從庫會慢慢趕上并與主庫一致，這種弱一致性的保證被稱為 最終一致性。

2.2 復制延遲問題

從上一小節中，我們知道了異步復制在寫入主庫到復制到從庫存在延遲，因此會產生一系列的問題，在這里我們對這些存在的問題進行更具體的解釋。

寫入完成后主節點失效，但從節點未完成數據同步

主節點失效，需要進行 故障轉移，將一個從庫提升為主庫，主庫的最佳人選通常是擁有最新數據副本的從庫（zookeeper的事務ID比較過程遵從的這個原理），讓新主庫來繼續為客戶端服務，其他從庫從新的主庫節點進行數據同步。

如果此時新的主節點在舊的主節點失效前還未完成數據同步，那么通常的做法是將原主節點未完成復制的數據丟棄，此時就會發生 數據丟失 的問題。

而且在舊的主庫恢復時，需要讓它意識到新主庫的存在，并使自己成為一個從庫。如果當集群中出現多個節點認為自己是主節點時，即 "腦裂" 現象，是非常危險的：因為多個主節點都可以進行寫操作，卻沒有沖突解決機制，數據就可能被破壞。

zookeeper出現腦裂時通過判斷 epoch 的大小（故障轉移完成新的一輪選舉之后它的epoch會遞增）來使從節點拒絕舊主節點的請求，保證數據不被破壞。

寫后讀一致性（讀己之寫一致性）

如上圖所示，如果用戶在寫入后馬上請求查看數據，則新數據可能尚未到達只讀從庫，看起來好像剛提交的數據丟失了，這種情況可以通過以下方式來解決

對于用戶 可能修改過 的內容，總是從主庫讀取，這需要有辦法在不通過查詢的方式來知道用戶是否修改了某些數據。比如，社交網絡的個人信息通常由個人來修改，因此可以定義總是從主庫來讀取自己的檔案信息，讀取其他人的信息則在從庫獲取

如果應用中的大部分內容都能被用戶修改，那么大部分查詢都從主庫讀取的話，讀伸縮性 就沒有效果了。在這種情況下可以通過記錄上次更新的時間，比如在更新后的一分鐘內從主庫查詢，之后在從庫讀取，以此來保證讀伸縮性

客戶端記錄最近一次的寫入時間戳，系統需要確保從庫在處理該用戶的讀請求時，該時間戳的變更已經在本從庫中記錄了，如果查詢的當前從庫不存在該記錄，那么需要再從其他從庫讀取，或者等待從庫同步數據

單調讀

如上圖所示，用戶1234寫入了一條評論，用戶2345在讀取其他用戶添加的評論時，第一次請求到了 Follower1，這時從庫已經完成了數據同步，那么能讀取到該評論。但是第二次請求到了 Follower2，而 Follower2 并沒有完成數據同步，導致看不到之前讀取到的評論，出現 "時間倒流" 現象。

避免這種現象需要保證 單調讀，即當用戶讀取到較新的數據時，他不會再讀取到更舊的數據。實現單調讀的方式是使 同一個用戶的讀請求都請求到同一個副本節點，我們可以根據ID的散列來分配副本而不是隨機分配。

2.3 新從庫的數據同步

通常為了增強系統的 讀伸縮性，會添加新的從庫。但新從庫在與主庫做數據同步時，簡單地將數據文件復制到另一個節點通常是不夠的，因為數據總是在不斷的變化，當前的數據文件不能包含全量數據，所以一般情況下的流程如下：

獲取某個時刻的主庫一致性快照，并將該快照復制到新的從庫節點

從庫連接到主庫，并拉取數據快照之后發生的數據變更，這就要求快照與主庫復制日志有精確的位置關聯，Mysql是通過 binlog coordinates 二進制日志坐標來關聯的

從庫處理完快照之后的數據變更，那么就說它趕上了主庫，現在它就可以及時處理主庫的數據變化了

如果發生 從庫失效，在從庫重新啟動后會執行以上 2,3 步驟，通過日志可以知道發生故障之前處理的最后一個事務，通過該記錄請求從庫斷開期間的所有數據變更，慢慢地追趕主庫。

3. 多主復制

基于單主節點的復制，每個寫請求都要經過主節點所在的數據中心，那么隨著寫入請求的增加，單主節點伸縮性差的局限性就會顯現出來，而且在世界各地的用戶都需要請求到該主節點才能進行寫入，可能存在延時較長的問題。為了解決這些問題，在單主節點架構下進行延伸，自然是 多主節點復制，在這種情況下，每個主節點又是其他主節點的從庫。

通常情況下，增加單主節點的伸縮性不會使用多主復制，而是通過數據分區來解決。因為前者導致的復雜性已經超過了它能帶來的好處，不過在某些情況下，也是可以采用多主復制的。

多數據中心的多主復制架構如下圖所示：

數據庫的副本分散在多個數據中心，在每個數據中心都有主庫，在每個數據中心內都是主從復制，每個數據中心的寫請求都會在本地數據中心處理然后同步到其他數據中心的主節點，這樣數據中心間的網絡延遲對用戶來說就變成了透明的，這 意味著性能可能會更好，對網絡問題的容忍度更高；多數據中心部署在不同的地理位置上，對用戶來說體驗更好；如果本地數據中心發生故障，能夠將請求轉移到其他數據中心，等本地數據中心恢復并復制趕上進度后，能繼續提供服務。

3.1 多主復制的應用場景

斷網后仍繼續工作的應用程序

如果你使用的手機和電腦是同一個生態的話，那么一般情況下，備忘錄內容的修改能在設備之間進行同步。從架構的角度來看，每個設備都相當于是一個數據中心，每個數據中心都能進行寫入，它符合多主復制模型。數據中心間的網絡是極度不可靠的，當手機離線，在電腦端對備忘錄進行修改后，那么當手機再接入互聯網，需要完成設備間的數據同步，這就是異步多主復制的過程。

在線協同文檔

當有用戶對文檔進行編輯時，所做的更改將立即被異步復制到服務器和其他任何正在使用該文檔的用戶，每個用戶操作的文檔都相當于是一個數據中心，這種情況與我們上文所述的在離線設備上對備忘錄進行修改有相似之處。不過，在這種情況下，為了加速協同和提高文檔的使用體驗，需要解決同時編輯產生的寫入沖突問題。

3.2 解決寫入沖突

雖然我們在上文中提到了多主復制能帶來諸多好處（多主帶來的伸縮性、更好的容錯機制和減少地理位置造成的延時），但是相伴的 配置復雜 和 寫入沖突問題 也是需要我們直面的。

如下圖所示，用戶1修改標題為B，用戶2修改標題為C，那么此時就會發生寫入沖突，我們很難說得清楚將誰的結果指定為最終修改結果是合適的，但是我們還是不得不將多主數據庫的值收斂至一致的狀態。

最后寫入勝利（LWW，last write wins） 是比較常用的方法，我們可以為每個請求增加時間戳或者唯一的ID，挑選其中較大的值作為最終結果，并將其他的值丟棄，不過這種情況容易造成數據丟失，比如在分布式服務中存在的 不可靠的時鐘 問題，可能后寫入的值反而攜帶的時間戳更靠前，那么這種情況下就會將我們預期被寫入的結果丟棄。

另一種方法是可以為每個主庫分配一個ID編號，具有更高的ID編號的主庫具有更高的優先級，但是這也會產生數據丟失問題。

如果不想發生數據丟失，可以以某種組合的方式將這些值組合在一起。以上圖中對標題的修改為例，可以將標題修改結果拼接成 B/C，不過這種情況需要用戶對結果進行修正。和該方式類似的，還可以考慮將所有對數據修改的沖突都顯示的記錄下來，之后提示用戶進行修改。

版本向量 也是一種解決沖突的方式。以緩存為例，我們為每個鍵維護一個版本號，每次寫入時先進行讀取，并且必須將之前讀取的所有值合并在一起，其中刪除的值會被標記（墓碑），這樣就能夠避免在合并完成后仍然出現曾刪掉的值。在寫入完成后版本號遞增，將新版本號與寫入的值一起存儲。在多個副本并發接受寫入時，每個副本也需要維護版本號，每個副本在處理寫入時增加自己的版本號。所有副本的版本號集合稱為 版本向量，版本向量會隨著讀取和寫入在客戶端和服務端之前來回傳遞，并且允許數據庫區分覆蓋寫入和并發寫入。版本向量能夠 確保從一個副本讀取并隨后寫回到另一個副本是安全的。

不過，雖然我們介紹了這么多解決沖突的方式，但是實際上 避免沖突 是最好的方式。比如我們可以確保特定記錄的所有寫入都通過同一個主庫，那么就不會發生沖突了。

關于并發的理解：如果是在單體服務中，我們可以通過時間戳來判斷兩個事件同時發生；如果是在分布式系統中，因為分布式系統存在不可靠的時鐘問題，所以在實際的系統中很難判斷兩個事件是否是同時發生，所以并發在 字面時間上的重疊并不重要。實際上，并發強調的是 兩個事件是否能意識到對方的存在，如果都意識不到對方的存在，即兩個事件都不在另一個之前發生，那么這兩個事件是并發的，那么它們存在需要被解決的 并發寫入 沖突。

5. 無主復制

無主復制與單主、多主復制采用不同的復制機制：它沒有主庫和從庫的職責差異，而是放棄了主庫的概念，每一個數據庫節點都可以處理寫入請求，因此它適用于 高可用、低延時、且能夠容忍偶爾讀到陳舊值 的應用場景。

這種復制模式還有一個好處是不存在故障轉移，當某個節點宕機時，應用會將該請求轉發到其他正常工作的節點。等到宕機節點重新連接之后，該節點可以通過以下兩種方式趕上錯過的寫入：

讀修復：適用于讀頻繁的值，客戶端并行獲取多個節點時，如果它檢測到陳舊的值，那么將讀取到的新值把陳舊的值覆蓋掉

反熵：開啟后臺進程，該進程不斷查找副本之間的數據差異，并將任何缺少的數據從一個副本復制到另一個副本

無主復制的每個數據庫節點都能處理讀寫請求，但是并不是在某單個節點寫入完成后就被認定為寫入成功或在單個節點讀取就認為該值是讀取結果。它的讀寫遵循 法定人數原則，與zookeeper處理寫入請求使用的容錯共識算法類似。

一般地說，如果有n個副本，每個寫入必須由 w 個節點確認才能被認為是成功的，并且每個讀取必須查詢 r 個節點。只要 w + r > n，我們可以預期在讀取時獲得最新的值，因為在 r 個讀取中至少有一個節點是最新的，遵循這些 r 值和 w 值的讀寫被稱為法定人數讀寫。常見的配置是將n（節點數）配置成奇數，并設置 w = r = (n + 1) / 2 向上取整，這樣保證了寫入和讀取的節點集合必然有重疊，所以讀取的節點中必然至少有一個節點具有最新的值。

如下圖所示，用戶1234會將寫入請求發送到所有的3個數據庫副本，并且在其中兩個副本返回成功時即認為寫入成功，而忽略了宕機副本錯過寫入的事實；用戶2345在讀取數據時，也會將請求發送到所有副本，并將其中最新的值看作讀取的結果。

每種復制的模式都有優點和缺點，單主復制是比較流行的，它容易理解而且無需處理沖突問題（寫入只有主節點處理）。不過在節點故障或者網絡出現較大的延時時，多主復制和無主復制可以更加健壯，但是它們只能提供較弱的一致性保證。

巨人的肩膀

《數據密集型應用系統設計》：第五章 復制

Replication（上）：常見復制模型&分布式系統挑戰

審核編輯 黃宇