hello大家好，我是城鄉經濟網小晟來為大家解答以上問題，數據容災方案推薦，高可用容災架構演進之路）很多人還不知道，現在讓我們一起來看看吧！

(資料圖片僅供參考)

隨著移動互聯網的深入發展，用戶增長達到一定規模后，不少企業都會面高并發業務和臨海量數據的挑戰，傳統的單機房在機器容量上存在瓶頸。在一些極端場景下，有可能所有服務器都出現故障，例如機房斷電、機房火災、地震等這些不可抗拒因素會導致系統所有服務器都故障從而導致業務整體癱瘓，而且即使有其他地區的備份，把備份業務系統全部恢復到能夠正常提供業務，花費的時間也比較長。為了滿足中心業務連續性，增強抗風險能力，多活作為一種可靠的高可用部署架構，成為各大互聯網公司的首要選擇。

對于系統高可用來說，相信大家都知道如下新聞：

而高可用這個概念，通常用 2 個指標來衡量：

可用性與這兩者的關系：

可用性（Availability）= MTBF / (MTBF MTTR) * 100%

這個公式得出的結果是一個「比例」，通常我們會用「N 個 9」來描述一個系統的可用性。

從這張圖你可以看到，要想達到 4 個 9 以上的可用性，平均每天故障時間必須控制在 10 秒以內。

也就是說，只有故障的時間「越短」，整個系統的可用性才會越高，每提升 1 個 9，都會對系統提出更高的要求。

如何從故障中快速恢復系統訪問，是對技術架構來說是一個很大的挑戰，接下來將和大家介紹高可用架構容災演進之路。

目前主要的容災類型可以分為以下三類：

沒有一套容災方案可以適用于所有場景，我們需要結合實際業務發展趨勢、業務系統的特征以及能夠投入多少資源成本等方面綜合評估，最終選出最適合的容災架構方案。

同城災備實際上是一種冷備，同一個城市至少部署兩個機房A、B，B備機房平時不提供服務能力，主要作為A主機房的備份，主備之間數據采用單向同步的形式，這兩個機房的網絡用一條「專線」連通。

A 機房整個掛掉，我們只需要做 2 件事即可：

這樣一來，恢復速度快了很多，提高了整個系統的高可用。

到這里你會發現，B 機房從最開始的「空空如也」，演變到現在，幾乎是「鏡像」了一份 A 機房的所有東西，從最上層的接入層，到中間的業務應用，到最下層的存儲。兩個機房唯一的區別是，A 機房的存儲都是主庫，而 B 機房都是從庫。

這種冷備方案的優劣勢如下：

優勢：

劣勢：

從整個高可用角度來說，同城災備是最初級的容災設計方案，數據不完整、恢復數據期間業務不可用，整個系統的可用性還是無法得到保證，DNS解析切換至少需要10分鐘以上，整個故障恢復來說也需要一些時間。

同城雙活是在同城或相近區域內建立兩個機房。同城雙機房距離比較近，通信線路質量較好，比較容易實現數據的同步復制 ，保證高度的數據完整性和數據零丟失。同城兩個機房各承擔一部分流量，一般入口流量完全隨機，內部RPC調用盡量通過就近路由閉環在同機房，相當于兩個機房鏡像部署了兩個獨立集群，數據仍然是單點寫到主機房數據庫，然后實時同步到另外一個機房。

因為 A 機房的存儲都是主庫，所以我們把 A 機房叫做「主機房」，B 機房叫「從機房」，部署架構如下圖：

業務應用在操作數據庫時，需要區分「讀寫分離」（一般用中間件實現），即兩個機房的「讀」流量，可以讀任意機房的存儲，但「寫」流量，只允許寫 A 機房，因為主庫在 A 機房。

這種方案的優劣勢如下：

優勢：

劣勢：

業務改造完成后，B 機房可以慢慢接入流量，從 10%、30%、50% 逐漸覆蓋到 100%，你可以持續觀察 B 機房的業務是否存在問題，有問題及時修復，逐漸讓 B 機房的工作能力，達到和 A 機房相同水平。

現在，因為 B 機房實時接入了流量，此時如果 A 機房掛了，那我們就可以「大膽」地把 A 的流量，全部切換到 B 機房，完成快速切換！

到這里你可以看到，我們部署的 B 機房，在物理上雖然與 A 有一定距離，但整個系統從「邏輯」上來看，我們是把這兩個機房看做一個「整體」來規劃的，也就是說，相當于把 2 個機房當作 1 個機房來用。

其實真正意義上的同城多活是指應用層多活和數據層同時多活，只有這2層多活，才能達到實際的流量切換與連續業務，當然在實施過程中從開發效率及商業目標等考慮，會使用一些偽同城多活的方案，如早期阿里為了應對雙11購物，杭州機房與上海機房采用的就是偽同城多活，應用層多活，2個應用節點同時寫一個機房數據，并且很好的解決雙11大流量購物需求。同城多活里，同城應用可以跨機房寫數據庫，應用層面的多活就實現了。而在強化了應用層面的容錯和故障處置手段之后，因為同城的數據傳輸延遲小，在主數據庫故障時，應用可快速把主數據庫切換到其他機房的從數據庫。在這種機制下，不單可以實現數據庫的多活，而且進一步實現了數據中心層面的同城多活，理論上任何一個數據中心中斷都不會導致業務中斷，切換過程也非常簡單。

基于上面同城雙活方案，有一個問題是無法解決的，無法抵抗地震、水災這種級別問題，引來了可以考慮增加一個異地冗余冷備，通常建議冗余冷備機房同中心機房的距離要在 1000 公里以上，這樣才能應對城市級別的災難，也就是本章節要介紹的兩地三中心方案。

假設之前的 A、B 機房在北京，那這次新部署的 C 機房可以放在上海。

兩地是指 2 個城市，三中心是指有 3 個機房，其中 2 個機房在同一個城市，并且同時提供服務，第 3 個機房部署在異地，只做數據災備。

這種架構方案，通常用在銀行、金融、政企相關的項目中，例如工行號稱也是支持兩地三中心，支付寶目前實施的兩地五中心多活方案。它的問題還是前面所說的，啟用災備機房需要時間，而且啟用后的服務，不確定能否如期工作。

這種方案的優劣勢：

優勢：

劣勢：

上面的兩地三中心的方案，本質上還是同城雙活，異地數據備份，不能解決同城出現自然災害導致的高可用問題。

我們不再把 A、B 機房部署在同一個城市，而是分開部署，例如 A 機房放在北京，B 機房放在上海。

具體部署架構如下：

此時兩個機房都接入流量，那上海機房的請求，可能要去讀寫北京機房的存儲，這里存在一個很大的問題：網絡延遲。

因為兩個機房距離較遠，受到物理距離的限制，現在，兩地之間的網絡延遲就變成了「不可忽視」的因素了。

北京到上海的距離大約 1300 公里，即使架設一條高速的「網絡專線」，光纖以光速傳輸，一個來回也需要近 10ms 的延遲。

況且，網絡線路之間還會經歷各種路由器、交換機等網絡設備，實際延遲可能會達到 30ms ~ 100ms，如果網絡發生抖動，延遲甚至會達到 1 秒。

不止是延遲，遠距離的網絡專線質量，是遠遠達不到機房內網絡質量的，專線網絡經常會發生延遲、丟包、甚至中斷的情況。總之，不能過度信任和依賴「跨城專線」。

阿里巴巴早期的多活方案就是基于上述這種方案，如早期阿里為了應對雙11購物，杭州機房與上海機房采用的就是偽同城多活，應用層多活，2個應用節點同時寫一個機房數據，并且很好的解決雙11大流量購物需求。

嚴格來講，這種多活方案只是做到了應用多活，沒有做到數據存儲層的多活，屬于偽異地雙活方案。

要真正的做到異地雙活，需要在存儲層做一定的改造，兩個機房的存儲必須都是「主庫」，而且兩個機房的數據還要「互相同步」數據，即客戶端無論寫哪一個機房，都能把這條數據同步到另一個機房。因為只有兩個機房都擁有「全量數據」，才能支持任意切換機房，持續提供服務。

具體部署架構如下：

真正的異地雙活需要解決的最核心的問題是數據同步的問題，MySQL 本身就提供了雙主架構，它支持雙向復制數據，但平時用的并不多。而且 Redis、MongoDB 等數據庫并沒有提供這個功能，所以，你必須開發對應的「數據同步中間件」來實現雙向同步的功能。

此外，除了數據庫這種有狀態的軟件之外，你的項目通常還會使用到消息隊列，例如 RocketMQ、Kafka，這些也是有狀態的服務，所以它們也需要開發雙向同步的中間件，支持任意機房寫入數據，同步至另一個機房。

業界也開源出了很多數據同步中間件，例如阿里的 Canal、RedisShake、MongoShake，可分別在兩個機房同步 MySQL、Redis、MongoDB 數據，阿里早期的數據同步使用的是DRC，目前阿里云上有相應的商業化產品DTS，支持關系型數據庫、NoSQL、大數據(OLAP)等數據源實時同步。

基于上述數據同步的中間件，具體部署方案如下：

使用數據同步的中間件解決了數據同步的問題，但同時帶來了一個很嚴重的問題，就是數據沖突的問題，兩個機房操作同一條數據記錄，尤其對于交易來說數據一致性要求比較高的應用而言，這是一個必須要解決的問題。

阿里實施異地雙活的解決方案，稱之為單元化，接下來具體講一下何為單元化。

具體來講就是，要在最上層就把用戶「區分」開，部分用戶請求固定打到北京機房，其它用戶請求固定打到上海 機房，進入某個機房的用戶請求，之后的所有業務操作，都在這一個機房內完成，從根源上避免「跨機房」。

所以這時，你需要在接入層之上，再部署一個「路由層」（通常部署在云服務器上），自己可以配置路由規則，把用戶「分流」到不同的機房內。

具體部署架構：

常見的路由方案：

舉例：假設我們一共有 4 個應用，北京和上海機房都部署這些應用。但應用 1、2 只在北京機房接入流量，在上海機房只是熱備。應用 3、4 只在上海機房接入流量，在北京機房是熱備。

這樣一來，應用 1、2 的所有業務請求，只讀寫北京機房存儲，應用 3、4 的所有請求，只會讀寫上海機房存儲。

最上層的路由層，會根據用戶 ID 計算「哈希」取模，然后從路由表中找到對應的機房，之后把請求轉發到指定機房內。

舉例：一共 200 個用戶，根據用戶 ID 計算哈希值，然后根據路由規則，把用戶 1 - 100 路由到北京機房，101 - 200 用戶路由到上海機房，這樣，就避免了同一個用戶修改同一條數據的情況發生。

這種方案，非常適合與地理位置密切相關的業務，例如打車、外賣服務就非常適合這種方案。

拿外賣服務舉例，你要點外賣肯定是「就近」點餐，整個業務范圍相關的有商家、用戶、騎手，它們都是在相同的地理位置內的。

針對這種特征，就可以在最上層，按用戶的「地理位置」來做分片，分散到不同的機房。

舉例：北京、河北地區的用戶點餐，請求只會打到北京機房，而上海、浙江地區的用戶，請求則只會打到上海機房。這樣的分片規則，也能避免數據沖突。

總之，分片的核心思路在于，讓同一個用戶的相關請求，只在一個機房內完成所有業務閉環，不再出現跨機房訪問，這就是所謂的單元化，阿里巴巴的淘系異地多活基于用戶ID的路由實現的單元化。

兩個機房就可以都接收「讀寫」流量（做好分片的請求），底層存儲保持「雙向」同步，兩個機房都擁有全量數據，當任意機房故障時，另一個機房就可以「接管」全部流量，實現快速切換，至此，我們才算實現了真正的異地雙活。

真正實施異地多活的成本是非常高的，這里面涉及到路由規則、路由轉發、數據同步中間件、數據校驗兜底策略，不僅需要開發強大的中間件，同時還要業務配合改造（業務邊界劃分、依賴拆分）等一些列工作，沒有足夠的人力物力，這套架構很難實施，不過隨著云計算的技術發展，目前對于一些中小企業來講，在一定程度降低了實施異地多活的成本。

理解了異地雙活，那「異地多活」顧名思義，就是在異地雙活的基礎上，部署多個機房即可。架構變成了這樣：

這些服務按照「單元化」的部署方式，可以讓每個機房部署在任意地區，隨時擴展新機房，你只需要在最上層定義好分片規則就好了。

但這里還有一個小問題，隨著擴展的機房越來越多，當一個機房寫入數據后，需要同步的機房也越來越多，這個實現復雜度會比較高。

所以業界又把這一架構又做了進一步優化，把「網狀」架構升級為「星狀」：

這種方案必須設立一個中心機房，任意機房寫入數據后，都只同步到中心機房，再由中心機房同步至其它機房。

這樣做的好處是，一個機房寫入數據，只需要同步數據到中心機房即可，不需要再關心一共部署了多少個機房，實現復雜度大大簡化。

但與此同時，這個中心機房的穩定性要求會比較高。不過也還好，即使中心機房發生故障，我們也可以把任意一個機房，提升為中心機房，繼續按照之前的架構提供服務。

異地多活方案的優劣：

優勢：

劣勢：

全球化多活指的是業務部署在不同國家的多個機房。相比跨城異地，跨國異地的距離就更遠了，因此數據同步的延時會更長，正常情況下可能就有幾秒鐘了。這種程度的延遲已經無法滿足異地多活標準的第一條：“正常情況下，用戶無論訪問哪一個地點的業務系統，都能夠得到正確的業務服務”。例如，假設有一個微博類網站，分別在中國的上海和美國的紐約都建了機房，用戶 A 在上海機房發表了一篇微博，此時如果他的一個關注者 B 用戶訪問到美國的機房，很可能無法看到用戶 A 剛剛發表的微博。雖然跨城異地也會有此類同步延時問題，但正常情況下幾十毫秒的延時對用戶來說基本無感知的；而延時達到幾秒鐘就感覺比較明顯了。

因此，跨國異地的“多活”，和跨城異地的“多活”，實際的含義并不完全一致。跨國異地多活的主要應用場景一般有這幾種情況：

亞馬遜中國是為中國用戶服務的，而亞馬遜美國是為美國用戶服務的，亞馬遜中國的用戶如果訪問美國亞馬遜，是無法用亞馬遜中國的賬號登錄美國亞馬遜的。

谷歌的搜索業務，由于用戶搜索資料時，這些資料都已經存在于谷歌的搜索引擎上面，無論是訪問英國谷歌，還是訪問美國谷歌，搜索結果基本相同，并且對用戶來說，也不需要搜索到最新的實時資料，跨國異地的幾秒鐘網絡延遲，對搜索結果是沒有什么影響的。

真正意義上的全球化多活，實施起來是非常困難的，因為跨國的延時問題不是秒級延時問題，更重要的跨國專線的穩定性，類似Facebook、Google這種對延時要求不敏感的業務相對來說還好一些，對于數據一致性要求比較高的業務很難做全球化多活，同時涉及到各國對于數據安全合規要求以及GDPR要求，很多國家的數據不允許回流到其他國家的，也就意味著不能回流到主數據中心的。

要想真正實現異地多活，還需要遵循一些原則，例如業務梳理、業務分級、數據分類、數據最終一致性保障、機房切換一致性保障、異常處理等等。同時，相關的運維設施、監控體系也要能跟得上才行。

宏觀上需要考慮業務（微服務部署、依賴、拆分、SDK、Web 框架）、基礎設施（服務發現、流量調度、持續集成、同步中間件、自研存儲），微觀上要開發各種中間件，還要關注中間件的高性能、高可用、容錯能力，其復雜度之高，尤其對于一些中小企業來講成本非常高的。

具體如何實施異地多活，可以分為如下4步：

按照一定的標準將業務進行分級，挑選出核心的業務，只為核心業務設計異地多活，降低方案整體復雜度和實現成本。

常見的分級標準有下面幾種：

以我們一直在舉例的用戶管理系統為例，“登錄”業務符合“訪問量大的業務”和“核心業務”這兩條標準，因此我們將登錄業務作為核心業務，阿里的異地多活并非所有的業務都實現多活。

挑選出核心業務后，需要對核心業務相關的數據進一步分析，目的在于識別所有的數據及數據特征，這些數據特征會影響后面的方案設計。

常見的數據特征分析維度有：

這里的數據量包括總的數據量和新增、修改、刪除的量。對異地多活架構來說，新增、修改、刪除的數據就是可能要同步的數據，數據量越大，同步延遲的幾率越高，同步方案需要考慮相應的解決方案。

唯一性指數據是否要求多個異地機房產生的同類數據必須保證唯一。例如用戶 ID，如果兩個機房的兩個不同用戶注冊后生成了一樣的用戶 ID，這樣業務上就出錯了。數據的唯一性影響業務的多活設計，如果數據不需要唯一，那就說明兩個地方都產生同類數據是可能的；如果數據要求必須唯一，要么只能一個中心點產生數據，要么需要設計一個數據唯一生成的算法。

實時性指如果在 A 機房修改了數據，要求多長時間必須同步到 B 機房，實時性要求越高，對同步的要求越高，方案越復雜。

可丟失性指數據是否可以丟失。例如，寫入 A 機房的數據還沒有同步到 B 機房，此時 A 機房機器宕機會導致數據丟失，那這部分丟失的數據是否對業務會產生重大影響。例如，登錄過程中產生的 session 數據就是可丟失的，因為用戶只要重新登錄就可以生成新的 session；而用戶 ID 數據是不可丟失的，丟失后用戶就會失去所有和用戶 ID 相關的數據，例如用戶的好友、用戶的錢等。

可恢復性指數據丟失后，是否可以通過某種手段進行恢復，如果數據可以恢復，至少說明對業務的影響不會那么大，這樣可以相應地降低異地多活架構設計的復雜度。例如，用戶的微博丟失后，用戶重新發一篇一模一樣的微博，這個就是可恢復的；或者用戶密碼丟失，用戶可以通過找回密碼來重新設置一個新密碼，這也算是可以恢復的；而用戶賬號如果丟失，用戶無法登錄系統，系統也無法通過其他途徑來恢復這個賬號，這就是不可恢復的數據。

確定數據的特點后，我們可以根據不同的數據設計不同的同步方案。常見的數據同步方案有：

這是最常用也是最簡單的同步方式。例如，使用 MySQL 的數據主從數據同步、主主數據同步。這類數據同步的優點是使用簡單，因為幾乎主流的存儲系統都會有自己的同步方案；缺點是這類同步方案都是通用的，無法針對業務數據特點做定制化的控制。例如，無論需要同步的數據量有多大，MySQL 都只有一個同步通道。因為要保證事務性，一旦數據量比較大，或者網絡有延遲，則同步延遲就會比較嚴重。

采用獨立消息隊列進行數據同步，常見的消息隊列有 Kafka、ActiveMQ、RocketMQ 等。消息隊列同步適合無事務性或者無時序性要求的數據。例如，用戶賬號，兩個用戶先后注冊了賬號 A 和 B，如果同步時先把 B 同步到異地機房，再同步 A 到異地機房，業務上是沒有問題的。而如果是用戶密碼，用戶先改了密碼為 m，然后改了密碼為 n，同步時必須先保證同步 m 到異地機房，再同步 n 到異地機房；如果反過來，同步后用戶的密碼就不對了。因此，對于新注冊的用戶賬號，我們可以采用消息隊列同步了；而對于用戶密碼，就不能采用消息隊列同步了。

不同步到異地機房，每個機房都可以生成數據，這個方案適合于可以重復生成的數據。例如，登錄產生的 cookie、session 數據、緩存數據等。

無論數據同步方案如何設計，一旦出現極端異常的情況，總是會有部分數據出現異常的。例如，同步延遲、數據丟失、數據不一致等。異常處理就是假設在出現這些問題時，系統將采取什么措施來應對。異常處理主要有以下幾個目的：

常見的異常處理措施有這幾類：

多通道同步的含義是采取多種方式來進行數據同步，其中某條通道故障的情況下，系統可以通過其他方式來進行同步，這種方式可以應對同步通道處故障的情況。以用戶管理系統中的用戶賬號數據為例，我們的設計方案一開始挑選了消息隊列的方式進行同步，考慮異常情況下，消息隊列同步通道可能中斷，也可能延遲很嚴重；為了保證新注冊賬號能夠快速同步到異地機房，我們再增加一種 MySQL 同步這種方式作為備份。這樣針對用戶賬號數據同步，系統就有兩種同步方式：MySQL 主從同步和消息隊列同步。除非兩個通道同時故障，否則用戶賬號數據在其中一個通道異常的情況下，能夠通過另外一個通道繼續同步到異地機房，如下圖所示。

多通道同步設計的方案關鍵點有：

這里的訪問指異地機房通過系統的接口來進行數據訪問。例如業務部署在異地兩個機房 A 和 B，B 機房的業務系統通過接口來訪問 A 機房的系統獲取賬號信息，如下圖所示。

同步和訪問結合方案的設計關鍵點有：

日志記錄主要用于用戶故障恢復后對數據進行恢復，其主要方式是每個關鍵操作前后都記錄相關一條日志，然后將日志保存在一個獨立的地方，當故障恢復后，拿出日志跟數據進行對比，對數據進行修復。為了應對不同級別的故障，日志保存的要求也不一樣，常見的日志保存方式有：

無論采用什么樣的異常處理措施，都只能最大限度地降低受到影響的范圍和程度，無法完全做到沒有任何影響。例如，雙同步通道有可能同時出現故障、日志記錄方案本身日志也可能丟失。因此，無論多么完美的方案，故障的場景下總是可能有一小部分用戶業務上出問題，系統無法彌補這部分用戶的損失。但我們可以采用人工的方式對用戶進行補償，彌補用戶損失，培養用戶的忠誠度。簡單來說，系統的方案是為了保證 99.99% 的用戶在故障的場景下業務不受影響，人工的補償是為了彌補 0.01% 的用戶的損失。常見的補償措施有送用戶代金券、禮包、禮品、紅包等，有時為了贏得用戶口碑，付出的成本可能還會比較大，但綜合最終的收益來看還是很值得的。例如暴雪《爐石傳說》2017 年回檔故障，暴雪給每個用戶大約價值人民幣 200 元的補償，結果玩家都求暴雪再來一次回檔，形象地說明了玩家對暴雪補償的充分認可。

異地多活，從整個業界的做法上來講，主要有幾家公司，比如Google、Facebook，這些是技術強悍切比較典型的，Google做到了全球多個數據中心，都是多活的。但是Google具體怎么做的，也沒有多少人了解。另外就是Facebook，我們相對更了解一些，Facebook在做多個數據中心時，比如說美國和歐洲兩個數據中心，確實都在支撐流量。但是歐洲的用戶有可能需要訪問美國的數據中心，當出現這種狀況時，整個用戶體驗不好。國內目前將異地多活做成熟的公司比較多，像阿里的單元化異地多活、餓了么、新浪微博、京東購物等，都已經做得非常成熟。

多活的技術成本非常高，每家公司都不斷在成本與業務之間綜合平衡各種利弊，選擇最好的方式服務業務。總之， 多活技術并不能100%解決全部業務多活，只能盡量保證絕大部分用戶的核心業務異地多活。

現代多活方案常常會利用云計算平臺的低部署和彈性運營成本與云計算平臺搭建混合云環境，比如阿里云提供了DTS能夠支撐關系型數據庫、NoSQL、大數據(OLAP)等數據源實時同步,同時提供了GSLB以及智能DNS解析，云解析 DNS 基于智能 DNS 解析做就近訪問。目前主流的 DNS 解析服務都能夠提供較為智能的解析線路，比如州級別、地域級別、國家級別等，在一定程度上降低了實施異地多活的成本。

分布式多活數據中心與云計算建設的思路既有相同之處也有差別，云的形成可以基于數據中心的分布式技術，建設模型更接近互聯網數據中心，而分布式多活數據中心的實現和實踐門檻相對要低，用戶在建設運維時更多的會關注于自身業務聯系性的要求與業務的快速響應及IT建設的持續優化，對復雜的企業級應用提供更好的支撐，使得IT建設更多的基于自身現有資源和能力。總之使用混合方式，而不盲目追求先進，體現了企業對于自身IT建設的把握與未來方向的掌控，是大型企業數據中心、大型多活系統持續穩健前行的必經之路。

災備高可用方案總結

1、同城災備分為「冷備」和「熱備」，冷備只備份數據，不提供服務，熱備實時同步數據，并做好隨時切換的準備

2、同城雙活比災備的優勢在于，兩個機房都可以接入「讀寫」流量，提高可用性的同時，還提升了系統性能。雖然物理上是兩個機房，但「邏輯」上還是當做一個機房來用

3、兩地三中心是在同城雙活的基礎上，額外部署一個異地機房做「災備」，用來抵御「城市」級別的災害，但啟用災備機房需要時間

4、異地雙活才是抵御「城市」級別災害的更好方案，兩個機房同時提供服務，故障隨時可切換，可用性高。但實現也最復雜，理解了異地雙活，才能徹底理解異地多活

5、異地多活是在異地雙活的基礎上，任意擴展多個機房，不僅又提高了可用性，還能應對更大規模的流量的壓力，擴展性最強，是實現高可用的最終方案

6、全球化多活指的是是業務部署在不同國家的多個機房，為不同地區的用戶提供服務，為全球用戶提供只讀服務。

具體實施經驗總結

1、異地多活雖然功能很強大，但也不是每個業務不管三七二十一都要上異地多。

2、如果業務規模很大，能夠做異地多活的情況下盡量實現異地多活。

3.異地多活設四大技巧

4.接口級故障的主要應對方案：降級、熔斷、限流、排隊。

本文就為大家講解到這里，希望對大家有所幫助。