作者：京東保險 王奕龍
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（上）：常見覆制模型&分散式系統挑戰