這篇文章主要講解了“跨地域場景下，怎么解決分布式系統(tǒng)的一致性”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“跨地域場景下，怎么解決分布式系統(tǒng)的一致性”吧！

創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供東海網(wǎng)站建設(shè)、東海做網(wǎng)站、東海網(wǎng)站設(shè)計、東海網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、東海企業(yè)網(wǎng)站模板建站服務(wù)，10余年東海做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

一 跨地域需求和挑戰(zhàn)

1 需求

跨地域問題是在集團全球化戰(zhàn)略下，業(yè)務(wù)快速發(fā)展帶來的挑戰(zhàn)。像是淘寶單元化業(yè)務(wù)，或是AliExpress區(qū)域化業(yè)務(wù)，都有一個無法回避的問題——數(shù)據(jù)跨區(qū)域讀寫一致性。

其核心需求可以總結(jié)為以下幾點：

跨地域業(yè)務(wù)場景

跨地域配置同步與服務(wù)發(fā)現(xiàn)是兩個常見的跨地域一致性協(xié)調(diào)服務(wù)的業(yè)務(wù)需求，跨地域部署可以提供就近訪問能力以減小服務(wù)延遲，根據(jù)具體業(yè)務(wù)場景可分為多地域?qū)懟蚝喕膯蔚赜驅(qū)憽娨恢滦宰x或最終一致性讀等場景?？绲赜虻臅捁芾砑盎诖说目绲赜蚍植际芥i也亟待提供成熟的解決方案。

服務(wù)、資源的拓展問題

當(dāng)一個地域內(nèi)某個機房的服務(wù)能力達到上限而又無法擴容，需要一致性系統(tǒng)在一個地域多個機房水平拓展和能夠跨地域拓展。

跨地域容災(zāi)能力

當(dāng)遭遇機房或者一個地域的災(zāi)難性故障時，需要一致性系統(tǒng)通過跨地域服務(wù)部署，將一個地域的業(yè)務(wù)迅速遷移到另一個地域完成災(zāi)備逃逸，實現(xiàn)高可用。

2 挑戰(zhàn)

綜合網(wǎng)絡(luò)延遲和業(yè)務(wù)需求，可以歸納出跨地域一致性系統(tǒng)所需要化解的挑戰(zhàn)：

延遲：網(wǎng)絡(luò)延遲達幾十毫秒

多地域部署帶來的核心問題便是網(wǎng)絡(luò)延遲高，以我們線上跨地域部署的跨地域集群為例，集群中機器分屬于杭州、深圳、上海、北京四個地域的機房，實際測試杭州機房到上海延遲大約6ms，到深圳和北京的延遲可以達到接近30ms。同機房或同地域機房間的網(wǎng)絡(luò)延遲一般在毫秒內(nèi)，相比之下跨地域訪問延遲上升了一個量級。

水平拓展：Quorum Servers規(guī)模受限

基于Paxos理論及其變種的分布式一致性系統(tǒng)，在拓展節(jié)點時不可避免會遇到Replication  Overhead問題，一般一個Quorum的節(jié)點數(shù)目不大于9個，故無法簡單地將一致性系統(tǒng)節(jié)點直接部署在多個地域，系統(tǒng)需要能持續(xù)地水平拓展，來滿足服務(wù)、資源的拓展需求。

存儲上限：單個節(jié)點存儲數(shù)據(jù)受限且failover恢復(fù)慢

無論是MySQL還是基于Paxos的一致性系統(tǒng)，其單個節(jié)點都會維護和加載全量的鏡像數(shù)據(jù)，會受到單臺集群容量的限制。同時在failover恢復(fù)時，若數(shù)據(jù)版本落后較多，通過拉取其他地域鏡像恢復(fù)會有較長的不可用時間。

二 我們的探索

1 業(yè)界解決方案

業(yè)界有針對跨地域的一致性系統(tǒng)有很多的設(shè)計，主要參考了論文[1]和一些開源的實現(xiàn)，下面介紹常見的幾種：

跨地域部署

圖1 直接跨地域部署

直接跨地域部署，讀請求直接讀本地域節(jié)點，速度較快，一致性、可用性由Paxos保證，沒有單點問題。缺點也很明顯，會遇到第一部分中講到的水平拓展問題，即Quorum拓展時會遇到Replication  Overhead問題。且隨著Quorum節(jié)點數(shù)目變多，在跨地域極高的網(wǎng)絡(luò)延遲下，每次多數(shù)派達成一致的時間會很長，寫效率很低。

單地域部署+Learner角色

圖2 引入Learner角色

通過引入Learner(例如zk中Observer、etcd的raft learner[2])  角色，即只進行數(shù)據(jù)同步而不參與多數(shù)派投票的角色，將寫請求轉(zhuǎn)發(fā)到某一個區(qū)域(如圖2中的Region  A)，來避免直接多節(jié)點部署的投票延時問題。此種方式可以解決水平拓展問題和延時問題，但由于參與投票的角色都部署在一個地域內(nèi)，當(dāng)此地域機房遇到災(zāi)難性時間時，寫服務(wù)便不可用了。此種方式是Otter[3]所采用的部署方式。

多服務(wù)+Partition&單地域部署+Learner

圖3 多個服務(wù)處理分Partition

將數(shù)據(jù)按規(guī)則切分為不同Partition，每個地域一個Quorum提供服務(wù)，不同地域Quorum負責(zé)不同Partition，地域之間Quorum使用Learner進行不同Partition數(shù)據(jù)同步及寫請求轉(zhuǎn)發(fā)，保證某區(qū)域出現(xiàn)問題只影響該區(qū)域Partition可用性。同時此種方案下會有正確性問題，即操作不符合順序一致性[4]的問題(見論文[1])。

實際實現(xiàn)時根據(jù)業(yè)務(wù)場景有各種解決方案，會針對性地進行優(yōu)化和權(quán)衡，彌補缺陷。業(yè)界較常見方案的是單地域部署+Learner角色這種方案，通過同城多活和Learner做跨地域數(shù)據(jù)同步來保證較高的可用性和較高的效率。其他方案也各有優(yōu)化方案，跨地域部署可以通過減少達成決議時地域間通信，來減小延時和帶寬問題，如TiDB的Follower  Replication[5];多服務(wù)+Partition&單地域部署+Learner這種方案的正確性也可以通過論文[1]中所述，在讀之前添加sync操作，犧牲一部分讀的可用性來保證一致性。

最后的結(jié)論如下表，后面會詳細闡釋其中的關(guān)鍵項：

2 跨地域的權(quán)衡

通過第一部分總結(jié)的需求挑戰(zhàn)和前面對業(yè)界跨地域一致性系統(tǒng)解決方案的調(diào)研，可以總結(jié)出基于Paxos的分布式一致性系統(tǒng)在跨地域場景下的核心權(quán)衡點：

• 寫操作跨地域走一致性協(xié)議達成決議太慢

• 地域內(nèi)多活無法提供極端情況下的可用性

• 需要具備分布式系統(tǒng)最核心的水平拓展能力

針對這三點問題，我們設(shè)計了一種日志鏡像解耦的跨地域一致性系統(tǒng)。

3 跨地域日志鏡像解耦

圖4 日志鏡像解耦示意圖

如圖3所示，我們的系統(tǒng)分為后端日志同步通道和前端全量狀態(tài)機——日志與鏡像解耦的架構(gòu)。后端跨地域全局日志同步通道，負責(zé)保證請求日志在各個區(qū)域的強一致性;前端全量狀態(tài)機部署在各地域內(nèi)，處理客戶端請求，也負責(zé)與后端日志服務(wù)交互，對外提供全局強一致性元數(shù)據(jù)訪問服務(wù)，接口可以根據(jù)業(yè)務(wù)需求快速修改狀態(tài)機來實現(xiàn)。

在全局日志與本地鏡像分離的架構(gòu)下，除了解耦本身帶來的系統(tǒng)運維和可拓展性的提升，我們還可以解決很多未解耦架構(gòu)下的問題，后面幾條分析是在此種架構(gòu)下如何對之前思考部分幾大問題的一個解決：

寫操作效率

單從部署的模式上看，看起來與直接多地域多節(jié)點部署，然后各地域添加Learner角色的做法類似，是直接多節(jié)點部署和引入Learner的一個結(jié)合，綜合了兩種方式的優(yōu)缺點。最大區(qū)別在于，我們的日志和鏡像解耦了，也就是說跨地域的部分是足夠輕量高效的單純?nèi)罩就?，且由于每個地域只有一個節(jié)點，能夠節(jié)省跨地域帶寬(類似TiDB的Follower  Replication)。同時后端日志同步通道，也可以實現(xiàn)多Group的功能，將數(shù)據(jù)分成Partition，每個一致性Group負責(zé)不同的Partiton。

由于大部分業(yè)務(wù)場景的讀操作為讀本地數(shù)據(jù)，各種方式相差不大，主要進行寫操作的延遲分析，下面是對于寫操作(或強一致性讀)的延遲分析：

RTT(Round-Trip  Time)，可以簡單理解為發(fā)送消息方從發(fā)送請求到得到響應(yīng)所經(jīng)過的時間。由于跨地域網(wǎng)絡(luò)延遲較大，后面RTT主要指跨地域RTT。

(1)直接跨地域部署

對于一個常見的有主一致性協(xié)議，我們的請求分兩種情況：

訪問Leader所在地域 1個RTT(暫時忽略地域內(nèi)較小的延遲)

Client -> Leader ----> Follower ----> Leader -> Client

訪問Follower所在地域 2個RTT

Client -> Follower ----> Leader ----> Follower ----> Leader ----> Follower ->

(2)單地域部署+Learner同步

在地域內(nèi)多活，地域間Learnner同步的方案中，我們的延時為：

本地域 0個RTT

Client -> Quorum -> Client

地域間 1個RTT

Client -> Learner ----> Quorum ----> Learner -> Client

(3)多服務(wù)Partition，單地域部署+Learner同步(與B結(jié)果類似)

寫本地域Partition 0個RTT

跨Partition寫 1個RTT

(4)日志鏡像解耦的架構(gòu)(與A結(jié)果類似)

寫本地域Partiton 1個RTT

Client ->Frontend -> LogChannel(local) ----> LogChannel (peer) ----> LogChannel (local) -> Frontend -> Client

跨Partition寫 2個RTT (Paxos兩階段提交/轉(zhuǎn)發(fā)leader)

Client ->Frontend -> LogChannel (local) ----> LogChannel (peer) ----> LogChannel (local) ----> LogChannel (peer) ----> LogChannel (local) -> Frontend -> Client

經(jīng)過以上的對比，可以看出只要跨地域走一致性協(xié)議進行寫操作，最少也會有1個RTT的延遲，而如果將Paxos  Quorum只部署在單地域，又不能保證任何極端情況下的可用性。所以我們根據(jù)業(yè)務(wù)需要，可以進行可用性和寫效率的權(quán)衡，日志鏡像解耦的架構(gòu)可以在多地域部署場景下保證極端的可用性和正確性，當(dāng)然效率上會比單地域部署+learner稍差一些，但如果采用多整體比直接多地域部署的方式要輕量高效，因為Quorum規(guī)模不會因水平拓展增加，不會影響投票效率。與多服務(wù)分Partition部署的方案則沒有效率優(yōu)勢，但在可運維護性、正確性、可用性這些方面都有優(yōu)勢。

一致性

跨地域部署和單地域部署+Learner的強一致性是滿足的，zookeeper和etcd都有對應(yīng)的介紹，在此不做贅述。多服務(wù)Partition分Partion這種方案不滿足順序一致性，主要是因為多服務(wù)不能保證每條寫操作commit的順序性，見下圖：

圖5 順序一致性

可以看到，當(dāng)兩個Client同時對x,y進行修改時，在寫操作并發(fā)程度較高的情況下，不能保證順序一致性。

順序一致性即可以將各個Client的操作排列出一個正確順序，在圖4的例子中：

set1(x,5) => get1(y)->0 => set2(y,3) => get2(x)->5

或者

set2(y,3) => get2(x)->0 => set2(y,3) => get1(y)->3

都是符合順序一致性的。

日志鏡像解耦的架構(gòu)的一致性可以簡單理解為跨地域部署+Learner，寫操作有sync選項，會在后端log提交成功并拉取到對應(yīng)log時才會返回成功，因此一定是可以拉取到其他Client在此操作之前的寫操作對應(yīng)的log，故符合順序一致性。

可用性

可用性這點與直接跨地域多節(jié)點部署的可用性類似，前端狀態(tài)機可以在某個地域后端節(jié)點掛掉情況下進行請求轉(zhuǎn)發(fā)，在后端全局日志服務(wù)不可用時也可以提供讀的可用性，可以提供極端情況下的讀寫高可用保證。

同時由于鏡像存儲在各個地域的狀態(tài)機中，當(dāng)某個前端狀態(tài)機掛掉時可以把客戶端切換到其他前端，failover恢復(fù)時也可以直接從后端拉取數(shù)據(jù)恢復(fù)，在落后太多情況下才需要從本地域其他前端拉取鏡像，不用跨地域同步鏡像，由此可以使得前端的不可用時間極短。

水平拓展能力

水平拓展能力是分布式服務(wù)的核心能力，在前述的多種方案中，直接跨地域部署水平拓展能力極差，其他依賴Learner的方式，也解決了水平拓展的問題，只是解耦沒有日志鏡像解耦的設(shè)計干凈。

將以上幾個關(guān)鍵問題總結(jié)對比：

三 跨地域更多可能性

后端日志和前端鏡像解耦的狀態(tài)下，我們對跨地域場景的探索分為兩部分——后端日志同步輕量高效和前端狀態(tài)機靈活豐富。

• 輕量，體現(xiàn)在架構(gòu)，后端只同步日志帶來的后端存儲壓力極小，只用同步輕量的增量日志。

• 高效，體現(xiàn)在后端的一致性協(xié)議，由于輕量，所以只需要考慮投票和選舉的邏輯，只用注重日志同步效率的提升，后端資源不用消耗在其他業(yè)務(wù)邏輯上。

• 靈活，體現(xiàn)在架構(gòu)，前端可以自定義上傳日志，CAS、事務(wù)等都可以包裝成日志由前端解析和處理。

• 豐富，主要是體現(xiàn)在前端的狀態(tài)機，由于日志的靈活留給我們探索和構(gòu)建的空間極大，可以根據(jù)需求包裝出處理各種復(fù)雜事務(wù)的狀態(tài)機。

新的架構(gòu)下有新的問題，這一部分主要探究如何吸取已有系統(tǒng)的優(yōu)點，利用日志鏡像解耦下的輕量、靈活，來實現(xiàn)跨地域場景下一致性協(xié)議和狀態(tài)機的高效、豐富，也會對跨地域一致性系統(tǒng)后繼如何發(fā)展有一個思考和規(guī)劃?？傮w目標(biāo)是后端一致性協(xié)議做精做深，前端狀態(tài)機做大做強。

1 高效的后端一致性協(xié)議

基于我們前面對寫操作效率的討論，在多地域?qū)懲粩?shù)據(jù)場景下，延遲只能控制在2RTT。因為跨地域場景下，延遲占比主要在跨地域網(wǎng)絡(luò)通信，無論是有主的轉(zhuǎn)發(fā)還是無主的Paxos兩階段提交，延遲都有2RTT。但如果使用無主的協(xié)議，如Paxos的變種EPaxos[6]，則可以盡可能提高跨地域場景下寫的效率，其延遲分Fast  Path和Slow Path兩種情況，在Fast Path下延遲為1RTT, Slow Path下延遲為2RTT。

引用介紹EPaxos文章中的一句話：

若并發(fā)提議的日志之間沒有沖突，EPaxos只需要運行PreAccept階段即可提交(Fast Path)，否則需要運行Accept階段才能提交(Slow  Path)。

相比于分Partition操作，如果將后端一致性協(xié)議選為EPaxos，則可以保證極端情況下的可用性和大多數(shù)情況下延遲為1RTT，這是無主一致性協(xié)議在跨地域場景下的優(yōu)勢，主要是因為省去了一次轉(zhuǎn)發(fā)Leader操作的RTT。目前我們系統(tǒng)中使用的是最基礎(chǔ)的Paxos的實現(xiàn)，在多地寫場景下延遲理論上與有主的協(xié)議相差不大，后繼發(fā)展期望利用EPaxos來加快跨地域場景下寫操作的效率。

由于不需要實現(xiàn)各種業(yè)務(wù)邏輯，高效便是后端一致性協(xié)議的最大訴求，當(dāng)然其正確性、穩(wěn)定性也是必不可少的，而對于前端的狀態(tài)機，則有著豐富的場景來設(shè)計和發(fā)揮。

CAS操作

CAS操作在此種架構(gòu)下的實現(xiàn)是很自然的，由于后端只有一致性log，所以我們每一次CAS請求，自然而然會有Commit的先后順序，舉一個例子。

兩個客戶端同時寫同一個Key的值：

圖 6 CAS操作示意圖

開始時key的值為0，此時Client 1和Client 2并發(fā)對key進行CAS操作，分別為CAS(key, 0, 1)和CAS(key, 0,  2)，當(dāng)這兩個操作同時提交并Commit后，由于后端Quorum達成決議的先后，Replication  Log一定會有先后順序，因此自然而然這兩個并發(fā)的CAS操作轉(zhuǎn)換為順序執(zhí)行。當(dāng)Frontend同步到這兩個操作的log時，會依次apply這兩個操作到本地狀態(tài)機，自然CAS(key,  0, 1)成功，更新key值為1，而CAS(key, 0, 2)更新失敗，這時前端會返回給對應(yīng)請求的Client其CAS請求是否成功或失敗的結(jié)果。

其原理是將一個并發(fā)操作變成了一個順序執(zhí)行的串行過程，由此避免了在跨地域場景下對加鎖的操作，可以想象如果是后端維護了一個kv結(jié)構(gòu)數(shù)據(jù)，則還需要增加一個跨地域分布式鎖來完成此操作，相對更加繁瑣，效率也沒有保證。通過只同步日志把復(fù)雜計算轉(zhuǎn)移到Frontend，可以靈活地構(gòu)建前端狀態(tài)機，更好地實現(xiàn)CAS或更復(fù)雜的事務(wù)功能(此種架構(gòu)可參考pravega的StateSynchronizer[7])。

Global ID

Global ID是一個常見的需求，分布式系統(tǒng)生成一個唯一ID，常見的有使用UUID、snow  flake算法，或者基于數(shù)據(jù)庫、redis、zookeeper的方案。

類似使用zookeeper的znode數(shù)據(jù)版本進行Global  ID的生成，在此種日志鏡像分離架構(gòu)中，可以使用CAS接口調(diào)用，生成一個key作為Global ID，每次對Global  ID進行原子操作。基于上述的CAS設(shè)計，跨地域并發(fā)場景下不需要加鎖，在使用方式上類似redis對key進行原子操作。

2 Watch操作

訂閱功能是分布式協(xié)調(diào)服務(wù)的不可或缺的，是業(yè)務(wù)最常見的一種需求，下面是對zk和etcd的調(diào)研結(jié)果：

目前業(yè)界比較成熟的實現(xiàn)了訂閱通知的分布式協(xié)調(diào)系統(tǒng)包括ETCD和ZooKeeper，我們分別以這兩個系統(tǒng)為例講解各自的解決方案。

ETCD會保存數(shù)據(jù)的多個歷史版本(MVCC)，通過單調(diào)遞增的版本號來表明版本的新舊，客戶端只要傳入自己關(guān)心的歷史版本，服務(wù)端就可以將后續(xù)的所有事件推送給客戶端。

Zookeeper并不會保存數(shù)據(jù)的多個歷史版本，只有當(dāng)前的數(shù)據(jù)狀態(tài)，客戶端并不能訂閱數(shù)據(jù)的歷史版本，客戶端只能訂閱當(dāng)前狀態(tài)之后的改變事件，所以訂閱伴隨著讀，服務(wù)端把當(dāng)前的數(shù)據(jù)發(fā)送給客戶端，然后推送后續(xù)的事件，同時為了防止在failover等異常場景訂閱到老的數(shù)據(jù)和事件，客戶端會拒絕連接數(shù)據(jù)比較老的服務(wù)端(這依賴于服務(wù)端會在每個請求會返回當(dāng)前的服務(wù)端全局的XID)。

上述的調(diào)研結(jié)果中ETCD較為符合我們的接口設(shè)計，目前ETCDv3  使用了HTTP/2的TCP鏈接多路復(fù)用，watch性能有提升。由于同為日志加狀態(tài)機結(jié)構(gòu)，設(shè)計功能時主要參考了ETCD  v3，借鑒其如何訂閱多個key以及返回全部歷史事件這兩個特性。若要達到etcd訂閱的功能，我們在前端狀態(tài)機同步并解析日志時，如果出現(xiàn)寫日志，則將kv結(jié)構(gòu)的狀態(tài)機Store和  專門提供給watch接口的狀態(tài)機watchableStore同時更新，具體實現(xiàn)可以完全參考etcd，然后按日志版本號將訂閱時版本后的歷史事件全部返回給客戶端。而訂閱多個key則同樣使用線段樹作為watcher的range  keys存儲結(jié)構(gòu)，可以實現(xiàn)watch范圍keys的watcher通知。

3 Lease機制

在無主的系統(tǒng)中實現(xiàn)高效的Lease機制是一大挑戰(zhàn)，無主的系統(tǒng)中沒有Leader，任意節(jié)點均可維護Lease，Lease分布在各個節(jié)點上，當(dāng)有節(jié)點不可用時，需要平滑切換到其它節(jié)點。無主的系統(tǒng)中實現(xiàn)高效的Lease機制的難點在于隨著Lease數(shù)量的增加，如何避免后端的一致性協(xié)議中出現(xiàn)大量的Lease維持消息，影響系統(tǒng)性能，最好讓Lease維持消息能夠直接在前端本地處理，而不經(jīng)過后端。所以我們的思路是將客戶端與前端的Lease聚合到前端與后端的Lease，使得Lease維持消息能夠直接在前端本地處理。

感謝各位的閱讀，以上就是“跨地域場景下，怎么解決分布式系統(tǒng)的一致性”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對跨地域場景下，怎么解決分布式系統(tǒng)的一致性這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！