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

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

• 2015 年 5 月 27 日，杭州市某地光纖被挖斷，近 3 億用戶長達 5 小時無法訪問支付寶
• 2021 年 7 月 13 日，B 站部分服務器機房發生故障，造成整站持續 3 個小時無法訪問
• 2021 年 10 月 9 日，富途證券服務器機房發生電力閃斷故障，造成用戶 2 個小時無法登陸、交易

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

• 平均故障間隔 MTBF（Mean Time Between Failure）：表示兩次故障的間隔時間，也就是系統「正常運行」的平均時間，這個時間越長，說明系統穩定性越高
• 故障恢複時間 MTTR（Mean Time To Repair）：表示系統發生故障後「恢複的時間」，這個值越小，故障對用戶的影響越小

可用性與這兩者的關系：

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

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

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

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

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

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

• 同城（跨可用區），主要分為同城災備、同城雙活以及同城多活。
• 異地（跨地域），主要分為異地雙讀、異地應用雙活以及異地雙活。
• 其他類型，包括兩地三中心、兩地三活以及單元化。

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

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

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

1. B 機房所有從庫提升為主庫
2. DNS 指向 B 機房接入層，接入流量，業務恢複

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

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

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

優勢：

• 部署簡單，将同一套架構完全複制到另外機房即可，數據做單向同步，對業務的改造極少。

劣勢：

• 為備數據中心存在資源浪費的情況；關鍵時刻不敢切流，容易出現版本、參數、操作系統不一緻等情況；
• 另外災備中心平時不會啟用，同城災備會造成一些物理資源的浪費。

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

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

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

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

這種方案的優劣勢如下：

優勢：

• 服務同城雙活，數據同城災備，同城不丢失數據情況下跨機房級别容災。
• 架構方案較為簡單，核心是解決底層數據雙活，由于雙機房距離近，通信質量好，底層儲存例如MySQL可以采用同步複制，有效保證雙機房數據一緻性。

劣勢：

• 數據庫寫數據存在跨機房調用，在複雜業務以及鍊路下頻繁跨機房調用增加響應時間，影響系統性能和用戶體驗。
• 保證同城市地區容災，當服務所在的城市或者地區網絡整體故障、發生不可抗拒的地震、水災等自然災害時候有服務故障以及丢失數據風險。
• 服務規模足夠大(例如單體應用超過萬台機器)，所有機器鍊接一個主數據庫實例會引起連接不足問題。
• 項目中用到了 MySQL、Redis、MongoDB 等等，操作這些數據庫，都需要區分讀寫請求，所以這塊需要一定的業務「改造」成本。

業務改造完成後，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 個機房部署在異地，隻做數據災備。

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

這種方案的優劣勢：

優勢：

• 服務同城雙活，數據同城災備，同城不丢失數據情況下跨機房級别容災。
• 架構方案較為簡單，核心是解決底層數據雙活，由于雙機房距離近，通信質量好，底層儲存例如mysql可以采用同步複制，有效保證雙機房數據一緻性。
• 災備中心能防範同城雙中心同時出現故障時候利用備份數據進行業務的恢複。

劣勢：

• 數據庫寫數據存在跨機房調用，在複雜業務以及鍊路下頻繁跨機房調用增加響應時間，影響系統性能和用戶體驗。
• 服務規模足夠大(例如單體應用超過萬台機器)，所有機器鍊接一個主數據庫實例會引起連接不足問題。
• 出問題不敢輕易将流量切往異地數據備份中心，異地的備份數據中心是冷的，平時沒有流量進入，因此出問題需要較長時間對異地災備機房進行驗證。
• 浪費硬件資源，冷備份中心正常情況下始終全量備份，不對外提供業務，很可能是長期一直不使用的情況。

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

我們不再把 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的路由實現的單元化。

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

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

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

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

但這裡還有一個小問題，随着擴展的機房越來越多，當一個機房寫入數據後，需要同步的機房也越來越多，這個實現複雜度會比較高。

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

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

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

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

異地多活方案的優劣：

優勢：

• 容災能力大幅度提高，服務異地多活，數據異地多活。
• 理論上系統服務可以水平擴展，異地多機房突破大幅度提升整體容量，理論上不會有性能擔憂。
• 将用戶流量切分到多個機房和地區去，有效能減少機房和地區級别的故障影響範圍。

劣勢：

• 架構非常複雜，部署和運維成本很高，需要對公司依賴的中間件、儲存做多方面能力改造。
• 對業務系統有一定的侵入性，由于單元化影響服務調用或者寫入數據要路由到對應的單元，業務系統需要設置路由标識(例如uid)。
• 無法完全避免跨單元、跨地區調用服務，例如上面的轉賬業務。我們要做的是盡力避免跨地區的服務調用。

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

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

• 為不同地區用戶提供服務

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

• 隻讀類業務做多活

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

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

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

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

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

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

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

• 訪問量大的業務以用戶管理系統為例，業務包括登錄、注冊、用戶信息管理，其中登錄的訪問量肯定是最大的。
• 核心業務以 QQ 為例，QQ 的主場景是聊天，QQ 空間雖然也是重要業務，但和聊天相比，重要性就會低一些，如果要從聊天和 QQ 空間兩個業務裡面挑選一個做異地多活，那明顯聊天要更重要（當然，此類公司如騰訊，應該是兩個都實現了異地多活的）。
• 産生大量收入的業務同樣以 QQ 為例，聊天可能很難為騰訊帶來收益，因為聊天沒法插入廣告；而 QQ 空間反而可能帶來更多收益，因為 QQ 空間可以插入很多廣告，因此如果從收入的角度來看，QQ 空間做異地多活的優先級反而高于 QQ 聊天了。

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

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

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

• 數據量

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

• 唯一性

唯一性指數據是否要求多個異地機房産生的同類數據必須保證唯一。例如用戶 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 機房的系統獲取賬号信息，如下圖所示。

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

• 接口訪問通道和數據庫同步通道不能采用相同的網絡連接，不能讓數據庫同步和接口訪問都走同一條網絡通道，可以采用接口訪問走公網連接，數據庫同步走内網連接這種方式。
• 數據有路由規則，可以根據數據來推斷應該訪問哪個機房的接口來讀取數據。例如，有 3 個機房 A、B、C，B 機房拿到一個不屬于 B 機房的數據後，需要根據路由規則判斷是訪問 A 機房接口，還是訪問 C 機房接口。
• 由于有同步通道，優先讀取本地數據，本地數據無法讀取到再通過接口去訪問，這樣可以大大降低跨機房的異地接口訪問數量，适合于實時性要求非常高的數據。

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

• 服務器上保存日志，數據庫中保存數據，這種方式可以應對單台數據庫服務器故障或者宕機的情況。
• 本地獨立系統保存日志，這種方式可以應對某業務服務器和數據庫同時宕機的情況。例如，服務器和數據庫部署在同一個機架，或者同一個電源線路上，就會出現服務器和數據庫同時宕機的情況。
• 日志異地保存，這種方式可以應對機房宕機的情況。上面不同的日志保存方式，應對的故障越嚴重，方案本身的複雜度和成本就會越高，實際選擇時需要綜合考慮成本和收益情況。

無論采用什麼樣的異常處理措施，都隻能最大限度地降低受到影響的範圍和程度，無法完全做到沒有任何影響。例如，雙同步通道有可能同時出現故障、日志記錄方案本身日志也可能丢失。因此，無論多麼完美的方案，故障的場景下總是可能有一小部分用戶業務上出問題，系統無法彌補這部分用戶的損失。但我們可以采用人工的方式對用戶進行補償，彌補用戶損失，培養用戶的忠誠度。簡單來說，系統的方案是為了保證 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.接口級故障的主要應對方案：降級、熔斷、限流、排隊。

• 降級的核心思想就是丢車保帥，優先保證核心業務。
• 限流指隻允許系統能夠承受的用戶量進來訪問，超出系統訪問能力

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!