分布式服務(wù)高可用實現(xiàn)：復(fù)制

1. 為什么需要復(fù)制

我們可以考慮如下問題：

1. 當(dāng)數(shù)據(jù)量、讀取或?qū)懭胴?fù)載已經(jīng)超過了當(dāng)前服務(wù)器的處理能力，如何實現(xiàn)負(fù)載均衡？
2. 希望在單臺服務(wù)器出現(xiàn)故障時仍能繼續(xù)工作，這該如何實現(xiàn)？
3. 當(dāng)服務(wù)的用戶遍布全球，并希望他們訪問服務(wù)時不會有較大的延遲，怎么才能統(tǒng)一用戶的交互體驗？

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

1. 采用無共享架構(gòu)（shared-nothing architecture），進行 橫向擴展，將數(shù)據(jù)分散到多臺服務(wù)器上，進行有效的 負(fù)載均衡，提高服務(wù)的 伸縮性
2. 部署多臺服務(wù)器，在一臺宕機時，其他服務(wù)器能隨時接管，實現(xiàn)服務(wù)的 高可用
3. 在多地理位置上部署服務(wù)，使用戶能就近訪問，避免產(chǎn)生較大的延遲，統(tǒng)一用戶體驗

2. 單主復(fù)制

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

• 其中一個副本被指定為 領(lǐng)導(dǎo)者，也稱為主庫，當(dāng)客戶端要向數(shù)據(jù)庫寫入時，它必須將該請求發(fā)送給領(lǐng)導(dǎo)者
• 其他副本被稱為 追隨者，也被稱為 從庫 或 只讀副本，每當(dāng)領(lǐng)導(dǎo)者將數(shù)據(jù)寫入本地存儲時，它會將數(shù)據(jù)變更以 復(fù)制日志 或 變更流 的形式推送給所有的追隨者，并且追隨者按照與領(lǐng)導(dǎo)者 相同的處理順序 來進行寫入

2.1 節(jié)點間的數(shù)據(jù)同步

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

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

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

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

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

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

2.2 復(fù)制延遲問題

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

• 寫入完成后主節(jié)點失效，但從節(jié)點未完成數(shù)據(jù)同步

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

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

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

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

---

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

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

• 對于用戶 可能修改過 的內(nèi)容，總是從主庫讀取，這需要有辦法在不通過查詢的方式來知道用戶是否修改了某些數(shù)據(jù)。比如，社交網(wǎng)絡(luò)的個人信息通常由個人來修改，因此可以定義總是從主庫來讀取自己的檔案信息，讀取其他人的信息則在從庫獲取
• 如果應(yīng)用中的大部分內(nèi)容都能被用戶修改，那么大部分查詢都從主庫讀取的話，讀伸縮性 就沒有效果了。在這種情況下可以通過記錄上次更新的時間，比如在更新后的一分鐘內(nèi)從主庫查詢，之后在從庫讀取，以此來保證讀伸縮性
• 客戶端記錄最近一次的寫入時間戳，系統(tǒng)需要確保從庫在處理該用戶的讀請求時，該時間戳的變更已經(jīng)在本從庫中記錄了，如果查詢的當(dāng)前從庫不存在該記錄，那么需要再從其他從庫讀取，或者等待從庫同步數(shù)據(jù)

---

• 單調(diào)讀

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

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

2.3 新從庫的數(shù)據(jù)同步

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

1. 獲取某個時刻的主庫一致性快照，并將該快照復(fù)制到新的從庫節(jié)點
2. 從庫連接到主庫，并拉取數(shù)據(jù)快照之后發(fā)生的數(shù)據(jù)變更，這就要求快照與主庫復(fù)制日志有精確的位置關(guān)聯(lián)，Mysql是通過 binlog coordinates 二進制日志坐標(biāo)來關(guān)聯(lián)的
3. 從庫處理完快照之后的數(shù)據(jù)變更，那么就說它趕上了主庫，現(xiàn)在它就可以及時處理主庫的數(shù)據(jù)變化了

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

3. 多主復(fù)制

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

通常情況下，增加單主節(jié)點的伸縮性不會使用多主復(fù)制，而是通過數(shù)據(jù)分區(qū)來解決。因為前者導(dǎo)致的復(fù)雜性已經(jīng)超過了它能帶來的好處，不過在某些情況下，也是可以采用多主復(fù)制的。

多數(shù)據(jù)中心的多主復(fù)制架構(gòu)如下圖所示：

數(shù)據(jù)庫的副本分散在多個數(shù)據(jù)中心，在每個數(shù)據(jù)中心都有主庫，在每個數(shù)據(jù)中心內(nèi)都是主從復(fù)制，每個數(shù)據(jù)中心的寫請求都會在本地數(shù)據(jù)中心處理然后同步到其他數(shù)據(jù)中心的主節(jié)點，這樣數(shù)據(jù)中心間的網(wǎng)絡(luò)延遲對用戶來說就變成了透明的，這 意味著性能可能會更好，對網(wǎng)絡(luò)問題的容忍度更高；多數(shù)據(jù)中心部署在不同的地理位置上，對用戶來說體驗更好；如果本地數(shù)據(jù)中心發(fā)生故障，能夠?qū)⒄埱筠D(zhuǎn)移到其他數(shù)據(jù)中心，等本地數(shù)據(jù)中心恢復(fù)并復(fù)制趕上進度后，能繼續(xù)提供服務(wù)。

3.1 多主復(fù)制的應(yīng)用場景

• 斷網(wǎng)后仍繼續(xù)工作的應(yīng)用程序

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

---

• 在線協(xié)同文檔

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

3.2 解決寫入沖突

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

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

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

另一種方法是可以為每個主庫分配一個ID編號，具有更高的ID編號的主庫具有更高的優(yōu)先級，但是這也會產(chǎn)生數(shù)據(jù)丟失問題。

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

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

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

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

5. 無主復(fù)制

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

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

• 讀修復(fù)：適用于讀頻繁的值，客戶端并行獲取多個節(jié)點時，如果它檢測到陳舊的值，那么將讀取到的新值把陳舊的值覆蓋掉
• 反熵：開啟后臺進程，該進程不斷查找副本之間的數(shù)據(jù)差異，并將任何缺少的數(shù)據(jù)從一個副本復(fù)制到另一個副本

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

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

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

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

轉(zhuǎn)載自：https://juejin.cn/post/7431007636046839817