異地多活，作為一種高可用部署架構(gòu)，成為大中型互聯(lián)網(wǎng)公司的選擇。像大家熟知的大型互聯(lián)網(wǎng)公司，如阿里、騰訊、百度、網(wǎng)易、新浪等等都已經(jīng)完成了異地多活的技術(shù)重構(gòu)。

[[353194]] 

圖片來自 Pexels

可以說，異地多活是互聯(lián)網(wǎng)公司業(yè)務(wù)規(guī)模擴(kuò)大后所必然要經(jīng)歷的階段。那么如何解決高可用異地多活呢?

有狀態(tài)服務(wù)

后臺服務(wù)可以劃分為兩類，有狀態(tài)和無狀態(tài)。高可用對于無狀態(tài)的應(yīng)用來說是比較簡單的，無狀態(tài)的應(yīng)用，只需要通過 F5 或者任何代理的方式就可以很好的解決。

后文描述的主要是針對有狀態(tài)的服務(wù)進(jìn)行分析。服務(wù)端進(jìn)行狀態(tài)維護(hù)主要是通過磁盤或內(nèi)存進(jìn)行保存，比如 MySQL 數(shù)據(jù)庫，Redis 等內(nèi)存數(shù)據(jù)庫。

除了這兩種類型的維護(hù)方式，還有 JVM 的內(nèi)存的狀態(tài)維持，但 JVM 的狀態(tài)生命周期通常很短。

高可用的一些解決方案

高可用，從發(fā)展來看，大致經(jīng)過了這幾個過程：

• 冷備
• 雙機(jī)熱備
• 同城雙活
• 異地雙活
• 異地多活

在聊異地多活的時候，還是先看一些其他的方案，這有利于我們理解很多設(shè)計(jì)的緣由。

冷備

冷備，通過停止數(shù)據(jù)庫對外服務(wù)的能力，通過文件拷貝的方式將數(shù)據(jù)快速進(jìn)行備份歸檔的操作方式。

簡而言之，冷備，就是復(fù)制粘貼，在 Linux 上通過 cp 命令就可以很快完成?？梢酝ㄟ^人為操作，或者定時腳本進(jìn)行。

有如下好處：

• 簡單
• 快速備份(相對于其他備份方式)
• 快速恢復(fù)。只需要將備份文件拷貝回工作目錄即完成恢復(fù)過程(亦或者修改數(shù)據(jù)庫的配置，直接將備份的目錄修改為數(shù)據(jù)庫工作目錄)。更甚，通過兩次 mv 命令就可瞬間完成恢復(fù)。
• 可以按照時間點(diǎn)恢復(fù)。比如，幾天前發(fā)生的拼多多優(yōu)惠券漏洞被人刷掉很多錢，可以根據(jù)前一個時間點(diǎn)進(jìn)行還原，“挽回?fù)p失”。

以上的好處，對于以前的軟件來說，是很好的方式。但是對于現(xiàn)如今的很多場景，已經(jīng)不好用了，因?yàn)椋?/p>

• 服務(wù)需要停機(jī)。N 個 9 肯定無法做到了。然后，以前我們的停機(jī)冷備是在凌晨沒有人使用的時候進(jìn)行，但是現(xiàn)在很多的互聯(lián)網(wǎng)應(yīng)用已經(jīng)是面向全球了，所以，任何時候都是有人在使用的。
• 數(shù)據(jù)丟失。如果不采取措施，那么在完成了數(shù)據(jù)恢復(fù)后，備份時間點(diǎn)到還原時間內(nèi)的數(shù)據(jù)會丟失。

傳統(tǒng)的做法，是冷備還原以后，通過數(shù)據(jù)庫日志手動恢復(fù)數(shù)據(jù)。比如通過 redo 日志，更甚者，我還曾經(jīng)通過業(yè)務(wù)日志去手動回放請求恢復(fù)數(shù)據(jù)?；謴?fù)是極大的體力活，錯誤率高，恢復(fù)時間長。

• 冷備是全量備份。全量備份會造成磁盤空間浪費(fèi)，以及容量不足的問題，只能通過將備份拷貝到其他移動設(shè)備上解決。

所以，整個備份過程的時間其實(shí)更長了。想象一下每天拷貝幾個T的數(shù)據(jù)到移動硬盤上，需要多少移動硬盤和時間。并且，全量備份是無法定制化的，比如只備份某一些表，是無法做到的。

如何權(quán)衡冷備的利弊，是每個業(yè)務(wù)需要考慮的。

雙機(jī)熱備

熱備，和冷備比起來，主要的差別是不用停機(jī)，一邊備份一邊提供服務(wù)。但還原的時候還是需要停機(jī)的。由于我們討論的是和存儲相關(guān)的，所以不將共享磁盤的方式看作雙機(jī)熱備。

①Active/Standby 模式

相當(dāng)于 1 主 1 從，主節(jié)點(diǎn)對外提供服務(wù)，從節(jié)點(diǎn)作為 backup。通過一些手段將數(shù)據(jù)從主節(jié)點(diǎn)同步到從節(jié)點(diǎn)，當(dāng)故障發(fā)生時，將從節(jié)點(diǎn)設(shè)置為工作節(jié)點(diǎn)。數(shù)據(jù)同步的方式可以是偏軟件層面，也可以是偏硬件層面的。

偏軟件層面的，比如 MySQL 的 master/slave 方式，通過同步 binlog 的方式;sqlserver 的訂閱復(fù)制方式。

偏硬件層面，通過扇區(qū)和磁盤的攔截等鏡像技術(shù)，將數(shù)據(jù)拷貝到另外的磁盤。偏硬件的方式，也被叫做數(shù)據(jù)級災(zāi)備;偏軟件的，被叫做應(yīng)用級災(zāi)備。后文談得更多的是應(yīng)用級災(zāi)備。

②雙機(jī)互備

本質(zhì)上還是 Active/Standby，只是互為主從而已。雙機(jī)互備并不能工作于同一個業(yè)務(wù)，只是在服務(wù)器角度來看，更好的壓榨了可用的資源。

比如，兩個業(yè)務(wù)分別有庫 A 和 B，通過兩個機(jī)器 P 和 Q 進(jìn)行部署。那么對于 A 業(yè)務(wù)，P 主 Q 從，對于 B 業(yè)務(wù)，Q 主 P 從。

整體上看起來是兩個機(jī)器互為主備。這種架構(gòu)下，讀寫分離是很好的，單寫多讀，減少沖突又提高了效率。

其他的高可用方案還可以參考各類數(shù)據(jù)庫的多種部署模式，比如 MySQL 的主從、雙主多從、MHA;Redis 的主從，哨兵，Cluster 等等。

同城雙活

前面講到的幾種方案，基本都是在一個局域網(wǎng)內(nèi)進(jìn)行的。業(yè)務(wù)發(fā)展到后面，有了同城多活的方案。

和前面比起來，不信任的粒度從機(jī)器轉(zhuǎn)為了機(jī)房。這種方案可以解決某個 IDC 機(jī)房整體掛掉的情況(停電，斷網(wǎng)等)。

同城雙活其實(shí)和前文提到的雙機(jī)熱備沒有本質(zhì)的區(qū)別，只是“距離”更遠(yuǎn)了，基本上還是一樣(同城專線網(wǎng)速還是很快的)。雙機(jī)熱備提供了災(zāi)備能力，雙機(jī)互備避免了過多的資源浪費(fèi)。

在程序代碼的輔助下，有的業(yè)務(wù)還可以做到真正的雙活，即同一個業(yè)務(wù)，雙主，同時提供讀寫，只要處理好沖突的問題即可。需要注意的是，并不是所有的業(yè)務(wù)都能做到。

業(yè)界更多采用的是兩地三中心的做法。遠(yuǎn)端的備份機(jī)房能更大的提供災(zāi)備能力，能更好的抵抗地震，恐襲等情況。雙活的機(jī)器必須部署到同城，距離更遠(yuǎn)的城市作為災(zāi)備機(jī)房。

災(zāi)備機(jī)房是不對外提供服務(wù)的，只作為備份使用，發(fā)生故障了才切流量到災(zāi)備機(jī)房;或者是只作為數(shù)據(jù)備份。原因主要在于：距離太遠(yuǎn)，網(wǎng)絡(luò)延遲太大。

圖 1：兩地三中心

如上圖，用戶流量通過負(fù)載均衡，將服務(wù) A 的流量發(fā)送到 IDC1，服務(wù)器集 A;將服務(wù) B 的流量發(fā)送到 IDC2，服務(wù)器 B。

同時，服務(wù)器集 a 和 b 分別從 A 和 B 進(jìn)行同城專線的數(shù)據(jù)同步，并且通過長距離的異地專線往 IDC3 進(jìn)行同步。

當(dāng)任何一個 IDC 當(dāng)機(jī)時，將所有流量切到同城的另一個 IDC 機(jī)房，完成了failover。

當(dāng)城市 1 發(fā)生大面積故障時，比如發(fā)生地震導(dǎo)致 IDC1 和 2 同時停止工作，則數(shù)據(jù)在 IDC3 得以保全。

同時，如果負(fù)載均衡仍然有效，也可以將流量全部轉(zhuǎn)發(fā)到 IDC3 中。不過，此時 IDC3 機(jī)房的距離非常遠(yuǎn)，網(wǎng)絡(luò)延遲變得很嚴(yán)重，通常用戶的體驗(yàn)的會受到嚴(yán)重影響的。

圖 2：兩地三中心主從模式

上圖是一種基于 Master-Slave 模式的兩地三中心示意圖。城市 1 中的兩個機(jī)房作為 1 主 1 從，異地機(jī)房作為從。

也可以采用同城雙主+Keepalived+VIP 的方式，或者 MHA 的方式進(jìn)行failover。但城市 2 不能(最好不要)被選擇為 Master。

異地雙活

同城雙活可以應(yīng)對大部分的災(zāi)備情況，但是碰到大面積停電，或者自然災(zāi)害的時候，服務(wù)依然會中斷。

對上面的兩地三中心進(jìn)行改造，在異地也部署前端入口節(jié)點(diǎn)和應(yīng)用，在城市 1 停止服務(wù)后將流量切到城市 2，可以在降低用戶體驗(yàn)的情況下，進(jìn)行降級。但用戶的體驗(yàn)下降程度非常大。

所以大多數(shù)的互聯(lián)網(wǎng)公司采用了異地雙活的方案：

圖 3：簡單的異地雙活示意圖

上圖是一個簡單的異地雙活的示意圖。流量經(jīng)過 LB 后分發(fā)到兩個城市的服務(wù)器集群中，服務(wù)器集群只連接本地的數(shù)據(jù)庫集群，只有當(dāng)本地的所有數(shù)據(jù)庫集群均不能訪問，才 failover 到異地的數(shù)據(jù)庫集群中。

在這種方式下，由于異地網(wǎng)絡(luò)問題，雙向同步需要花費(fèi)更多的時間。更長的同步時間將會導(dǎo)致更加嚴(yán)重的吞吐量下降，或者出現(xiàn)數(shù)據(jù)沖突的情況。

吞吐量和沖突是兩個對立的問題，你需要在其中進(jìn)行權(quán)衡。例如，為了解決沖突，引入分布式鎖/分布式事務(wù)。

為了解決達(dá)到更高的吞吐量，利用中間狀態(tài)、錯誤重試等手段，達(dá)到最終一致性;降低沖突，將數(shù)據(jù)進(jìn)行恰當(dāng)?shù)? sharding，盡可能在一個節(jié)點(diǎn)中完成整個事務(wù)。

對于一些無法接受最終一致性的業(yè)務(wù)，餓了么采用的是下圖的方式：

對于個別一致性要求很高的應(yīng)用，我們提供了一種強(qiáng)一致的方案(Global Zone)，Globa Zone 是一種跨機(jī)房的讀寫分離機(jī)制，所有的寫操作被定向到一個 Master 機(jī)房進(jìn)行，以保證一致性，讀操作可以在每個機(jī)房的 Slave 庫執(zhí)行，也可以 bind 到 Master 機(jī)房進(jìn)行，這一切都基于我們的數(shù)據(jù)庫訪問層(DAL)完成，業(yè)務(wù)基本無感知。

《餓了么異地多活技術(shù)實(shí)現(xiàn)(一)總體介紹》

也就是說，在這個區(qū)域是不能進(jìn)行雙活的。采用主從而不是雙寫，自然解決了沖突的問題。

實(shí)際上，異地雙活和異地多活已經(jīng)很像了，雙活的結(jié)構(gòu)更為簡單，所以在程序架構(gòu)上不用做過多的考慮，只需要做傳統(tǒng)的限流，failover 等操作即可。

但其實(shí)雙活只是一個臨時的步驟，最終的目的是切換到多活。因?yàn)殡p活除了有數(shù)據(jù)沖突上的問題意外，還無法進(jìn)行橫向擴(kuò)展。

異地多活

圖 4：異地多活的示意圖

根據(jù)異地雙活的思路，我們可以畫出異地多活的一種示意圖。每個節(jié)點(diǎn)的出度和入度都是 4，在這種情況下，任何節(jié)點(diǎn)下線都不會對業(yè)務(wù)有影響。

但是，考慮到距離的問題，一次寫操作將帶來更大的時間開銷。時間開銷除了影響用戶體驗(yàn)以外，還帶來了更多的數(shù)據(jù)沖突。

在嚴(yán)重的數(shù)據(jù)沖突下，使用分布式鎖的代價也更大。這將導(dǎo)致系統(tǒng)的復(fù)雜度上升，吞吐量下降。所以上圖的方案是無法使用的。

回憶一下我們在解決網(wǎng)狀網(wǎng)絡(luò)拓?fù)涞臅r候是怎么優(yōu)化的?引入中間節(jié)點(diǎn)，將網(wǎng)狀改為星狀：

圖 5：星狀的異地多活

改造為上圖后，每個城市下線都不會對數(shù)據(jù)造成影響。對于原有請求城市的流量，會被重新 LoadBalance 到新的節(jié)點(diǎn)(最好是 LB 到最近的城市)。

為了解決數(shù)據(jù)安全的問題，我們只需要針對中心節(jié)點(diǎn)進(jìn)行處理即可。但是這樣，對于中心城市的要求，比其他城市會更高。

比如恢復(fù)速度，備份完整性等，這里暫時不展開。我們先假定中心是完全安全的。

如果我們已經(jīng)將異地多活的業(yè)務(wù)部署為上圖的結(jié)構(gòu)，很大程度解決了數(shù)據(jù)到處同步的問題，不過依然會存在大量的沖突，沖突的情況可以簡單認(rèn)為和雙活差不多。那么還有沒有更好的方式呢?

回顧一下前文提到的餓了么的 GlobalZone 方案，總體思路就是“去分布式”，也就是說將寫的業(yè)務(wù)放到一個節(jié)點(diǎn)的(同城)機(jī)器上。

阿里是這么思考的：

阿里理想中的異地多活架構(gòu)

實(shí)際上我猜測很多業(yè)務(wù)也是按照上圖去實(shí)現(xiàn)的，比如滴滴打車業(yè)務(wù)這種，所有的業(yè)務(wù)都是按城市劃分開的。

用戶、車主、目的地，他們的經(jīng)緯度通常都是在同一個城市的。單個數(shù)據(jù)中心并不需要和其他數(shù)據(jù)中心進(jìn)行數(shù)據(jù)交互，只有在統(tǒng)計(jì)出報表的時候才需要，但報表是不太注重實(shí)時性的。

那么，在這種情況下，全國的業(yè)務(wù)其實(shí)可以被很好的 sharding 的。但是對于電商這種復(fù)雜的場景和業(yè)務(wù)，按照前文說的方式進(jìn)行 sharding 已經(jīng)無法滿足需求了。

因?yàn)闃I(yè)務(wù)線非常復(fù)雜，數(shù)據(jù)依賴也非常復(fù)雜，每個數(shù)據(jù)中心相互進(jìn)行數(shù)據(jù)同步的情況無可避免。

淘寶的解決方式和我們切分微服務(wù)的方式有點(diǎn)類似：

淘寶按照單元切分的異地多活架構(gòu)

注意看圖中的數(shù)據(jù)同步箭頭。以交易單元為例，屬于交易單元的業(yè)務(wù)數(shù)據(jù)，將與中心單元進(jìn)行雙向同步;不屬于交易單元的業(yè)務(wù)數(shù)據(jù)，單向從中心單元同步。

中心單元承擔(dān)了最復(fù)雜的業(yè)務(wù)場景，業(yè)務(wù)單元承擔(dān)了相對單一的場景。對于業(yè)務(wù)單元，可以進(jìn)行彈性伸縮和容災(zāi)。

對于中心單元，擴(kuò)展能力較差，穩(wěn)定性要求更高。可以遇見，大部分的故障都會出現(xiàn)在中心單元。

按照業(yè)務(wù)進(jìn)行單元切分，已經(jīng)需要對代碼和架構(gòu)進(jìn)行徹底的改造了(可能這也是為什么阿里要先從雙活再切到多活，歷時3年)。比如，業(yè)務(wù)拆分，依賴拆分，網(wǎng)狀改星狀，分布式事務(wù)，緩存失效等。

除了對于編碼的要求很高以外，對測試和運(yùn)維也有非常大的挑戰(zhàn)。如此復(fù)雜的情況，如何進(jìn)行自動化覆蓋，如何進(jìn)行演練，如何改造流水線。這種級別的災(zāi)備，不是一般公司敢做的，投入產(chǎn)出也不成正比。

不過還是可以把這種場景當(dāng)作我們的“假想敵”，去思考我們自己的業(yè)務(wù)，未來會怎么發(fā)展，需要做到什么級別的災(zāi)備。相對而言，餓了么的多活方案可能更適合大多數(shù)的企業(yè)。

本文只是通過畫圖的方式進(jìn)行了簡單的描述，其實(shí)異地多活是需要很多很強(qiáng)大的基礎(chǔ)能力的。

比如，數(shù)據(jù)傳輸，數(shù)據(jù)校驗(yàn)，數(shù)據(jù)操作層(簡化客戶端控制寫和同步的過程)等。

思考

最后，留幾個問題大家可以思考一下：

• 假設(shè)你在做餓了么的開發(fā)，服務(wù)按照異地多活方式部署，sharding key 根據(jù)省市區(qū)進(jìn)行分片。假設(shè)買家在多個城市交匯的地方，比如，十字路口的四個位置分別是 4 個城市，那么如何處理才能讓他拉到比較正常的數(shù)據(jù)?
• 你們現(xiàn)在的業(yè)務(wù)模塊中，哪些業(yè)務(wù)是可以做多活的，哪些無法做多活?
• 所有的業(yè)務(wù)都要做多活嗎?還是只需要核心業(yè)務(wù)做多活?

參考資料及其他資料：

• 《餓了么異地多活技術(shù)實(shí)現(xiàn)(一)總體介紹》

https://zhuanlan.zhihu.com/p/32009822

• 《餓了么框架工具部技術(shù)博客》

https://zhuanlan.zhihu.com/eleme-arch

• 《阿里異地多活與同城雙活的架構(gòu)演進(jìn)》

https://www.sohu.com/a/158859741_444159

• 《阿里云 數(shù)據(jù)庫異地多活解決方案》

https://help.aliyun.com/document_detail/72721.html

• 《異地多活沒那么難》

https://wely.iteye.com/blog/2313293

作者：DongGuoChao

編輯：陶家龍

出處：https://blog.dogchao.cn/?p=299