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

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

我們可以考慮如下問(wèn)題：

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

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

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

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

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

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

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

2. 單主復(fù)制

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

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

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

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

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

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

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

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

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

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

2.2 復(fù)制延遲問(wèn)題

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

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

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

而且在舊的主庫(kù)恢復(fù)時(shí)，需要讓它意識(shí)到新主庫(kù)的存在，并使自己成為一個(gè)從庫(kù)。如果當(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)行寫(xiě)操作，卻沒(méi)有沖突解決機(jī)制，數(shù)據(jù)就可能被破壞。

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

寫(xiě)后讀一致性（讀己之寫(xiě)一致性）

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

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

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

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

單調(diào)讀

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

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

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

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

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

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

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

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

3. 多主復(fù)制

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

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

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

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

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

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

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

在線協(xié)同文檔

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

3.2 解決寫(xiě)入沖突

雖然我們?cè)谏衔闹刑岬搅硕嘀鲝?fù)制能帶來(lái)諸多好處（多主帶來(lái)的伸縮性、更好的容錯(cuò)機(jī)制和減少地理位置造成的延時(shí)），但是相伴的 配置復(fù)雜 和 寫(xiě)入沖突問(wèn)題 也是需要我們直面的。

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

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

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

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

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

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

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

5. 無(wú)主復(fù)制

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

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

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

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

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

一般地說(shuō)，如果有n個(gè)副本，每個(gè)寫(xiě)入必須由 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 值的讀寫(xiě)被稱(chēng)為法定人數(shù)讀寫(xiě)。常見(jiàn)的配置是將n（節(jié)點(diǎn)數(shù)）配置成奇數(shù)，并設(shè)置 w = r = (n + 1) / 2 向上取整，這樣保證了寫(xiě)入和讀取的節(jié)點(diǎn)集合必然有重疊，所以讀取的節(jié)點(diǎn)中必然至少有一個(gè)節(jié)點(diǎn)具有最新的值。

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

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

巨人的肩膀

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

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

審核編輯 黃宇