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

作者：京東保險(xiǎn) 王奕龍

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

我們可以考慮如下問題：

當(dāng)數(shù)據(jù)量、讀取或?qū)懭胴?fù)載已經(jīng)超過了當(dāng)前服務(wù)器的處理能力，如何實(shí)現(xiàn)負(fù)載均衡？

希望在單臺服務(wù)器出現(xiàn)故障時(shí)仍能繼續(xù)工作，這該如何實(shí)現(xiàn)？

當(dāng)服務(wù)的用戶遍布全球，并希望他們訪問服務(wù)時(shí)不會(huì)有較大的延遲，怎么才能統(tǒng)一用戶的交互體驗(yàn)？

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

采用無共享架構(gòu)（shared-nothing architecture），進(jìn)行 橫向擴(kuò)展，將數(shù)據(jù)分散到多臺服務(wù)器上，進(jìn)行有效的 負(fù)載均衡，提高服務(wù)的 伸縮性

部署多臺服務(wù)器，在一臺宕機(jī)時(shí)，其他服務(wù)器能隨時(shí)接管，實(shí)現(xiàn)服務(wù)的 高可用

在多地理位置上部署服務(wù)，使用戶能就近訪問，避免產(chǎn)生較大的延遲，統(tǒng)一用戶體驗(yàn)

2. 單主復(fù)制

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

其中一個(gè)副本被指定為 領(lǐng)導(dǎo)者，也稱為主庫，當(dāng)客戶端要向數(shù)據(jù)庫寫入時(shí)，它必須將該請求發(fā)送給領(lǐng)導(dǎo)者

其他副本被稱為 追隨者，也被稱為 從庫 或 只讀副本，每當(dāng)領(lǐng)導(dǎo)者將數(shù)據(jù)寫入本地存儲(chǔ)時(shí)，它會(huì)將數(shù)據(jù)變更以 復(fù)制日志 或 變更流 的形式推送給所有的追隨者，并且追隨者按照與領(lǐng)導(dǎo)者 相同的處理順序 來進(jìn)行寫入

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

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

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

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

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

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

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

2.2 復(fù)制延遲問題

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

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

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

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

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

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

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

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

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

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

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

單調(diào)讀

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

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

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

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

獲取某個(gè)時(shí)刻的主庫一致性快照，并將該快照復(fù)制到新的從庫節(jié)點(diǎn)

從庫連接到主庫，并拉取數(shù)據(jù)快照之后發(fā)生的數(shù)據(jù)變更，這就要求快照與主庫復(fù)制日志有精確的位置關(guān)聯(lián)，Mysql是通過 binlog coordinates 二進(jìn)制日志坐標(biāo)來關(guān)聯(lián)的

從庫處理完快照之后的數(shù)據(jù)變更，那么就說它趕上了主庫，現(xiàn)在它就可以及時(shí)處理主庫的數(shù)據(jù)變化了

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

3. 多主復(fù)制

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

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

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

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

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

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

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

在線協(xié)同文檔

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

3.2 解決寫入沖突

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

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

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

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

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

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

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

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

5. 無主復(fù)制

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

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

讀修復(fù)：適用于讀頻繁的值，客戶端并行獲取多個(gè)節(jié)點(diǎn)時(shí)，如果它檢測到陳舊的值，那么將讀取到的新值把陳舊的值覆蓋掉

反熵：開啟后臺進(jìn)程，該進(jìn)程不斷查找副本之間的數(shù)據(jù)差異，并將任何缺少的數(shù)據(jù)從一個(gè)副本復(fù)制到另一個(gè)副本

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

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

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

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

巨人的肩膀

《數(shù)據(jù)密集型應(yīng)用系統(tǒng)設(shè)計(jì)》：第五章 復(fù)制

Replication（上）：常見復(fù)制模型&分布式系統(tǒng)挑戰(zhàn)

審核編輯 黃宇