作者:京東保險 王奕龍
1. 為什么需要復(fù)制
我們可以考慮如下問題:
當(dāng)數(shù)據(jù)量、讀取或?qū)懭胴?fù)載已經(jīng)超過了當(dāng)前服務(wù)器的處理能力,如何實現(xiàn)負(fù)載均衡?
希望在單臺服務(wù)器出現(xiàn)故障時仍能繼續(xù)工作,這該如何實現(xiàn)?
當(dāng)服務(wù)的用戶遍布全球,并希望他們訪問服務(wù)時不會有較大的延遲,怎么才能統(tǒng)一用戶的交互體驗?
這些問題其實都能通過 “復(fù)制” 來解決:復(fù)制,即在不同的節(jié)點上保存相同的副本,提供數(shù)據(jù)冗余。如果一些節(jié)點不可用,剩余的節(jié)點仍然可以提供數(shù)據(jù)服務(wù),這些節(jié)點可能部署在不同的地理位置,以此來改善系統(tǒng)性能,針對以上三個問題的解決方案如下:
采用無共享架構(gòu)(shared-nothing architecture),進行 橫向擴展,將數(shù)據(jù)分散到多臺服務(wù)器上,進行有效的 負(fù)載均衡,提高服務(wù)的 伸縮性
部署多臺服務(wù)器,在一臺宕機時,其他服務(wù)器能隨時接管,實現(xiàn)服務(wù)的 高可用
在多地理位置上部署服務(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ù),所以一般情況下的流程如下:
獲取某個時刻的主庫一致性快照,并將該快照復(fù)制到新的從庫節(jié)點
從庫連接到主庫,并拉取數(shù)據(jù)快照之后發(fā)生的數(shù)據(jù)變更,這就要求快照與主庫復(fù)制日志有精確的位置關(guān)聯(lián),Mysql是通過 binlog coordinates 二進制日志坐標(biāo)來關(guān)聯(lián)的
從庫處理完快照之后的數(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ù)制可以更加健壯,但是它們只能提供較弱的一致性保證。
巨人的肩膀
《數(shù)據(jù)密集型應(yīng)用系統(tǒng)設(shè)計》:第五章 復(fù)制
Replication(上):常見復(fù)制模型&分布式系統(tǒng)挑戰(zhàn)
審核編輯 黃宇
-
服務(wù)器
+關(guān)注
關(guān)注
12文章
8892瀏覽量
84995 -
數(shù)據(jù)庫
+關(guān)注
關(guān)注
7文章
3745瀏覽量
64190 -
分布式
+關(guān)注
關(guān)注
1文章
847瀏覽量
74428
發(fā)布評論請先 登錄
相關(guān)推薦
評論