摘要：異地多活，顧名思義就是分佈在異地多個站點同時對外提供服務，與傳統災備最主要的區別是“多活”裏所有站點都是同時在對外提供服務的。在業務不斷複雜化和容災要求不斷嚴格化的今天，如何實現雲原生的異地多活解決方案，成爲了中大型企業不得不面對的挑戰。在第十一屆中國數據庫技術大會（DTCC2020）上，阿里雲高級數據庫專家張鑫就爲大家分享了阿里云云原生異地多活解決方案。
本文內容根據演講錄音及PPT整理而成。
本次分享將主要分爲三個方面：
- 容災架構分析
- 阿里雲異地多活解決方案
- 異地多活客戶案例
一、容災架構分析
容災必要性
異地多活本身是從容災出發的，因此首先介紹一下容災的必要性。生產系統可能會遇到三類故障，第一個是主機級故障，如單點負載過高、數據損壞等；第二類是機房級故障，如供電故障、機房網絡故障等；第三類是地域級故障，如自然災害等。對於上述三類故障而言，顯然是地域級故障影響面最大，但發生概率最低，但對於主機級故障而言，卻並不一定發生概率低且影響面小。阿里巴巴對於自身多年來的故障類型做了梳理，發現隨着現在業務系統複雜度的增加，單點故障也可能會造成全局影響，而且當複雜度達到一定程度時，如果發生這種單點故障，排查和恢復都會非常困難，因此容災能力成爲了企業信息化建設的必選項。
容災架構演進
容災架構的演進主要分成幾個階段。同城容災最爲簡單，即在同一個地域內有一個IDC並部署了業務，容災時再部署一個機房備份系統和數據庫，在中間實現異步或者同步的數據同步，業務流量集中在一邊，另外一邊只做災備。後來逐漸演進出了同城雙活，其借用了同城內兩個數據中心地理距離比較近，網絡延遲較短的優勢，可以將業務部署到兩端，因爲物理距離較短，延遲等問題都可以接受。再往後就是異地雙活，即兩點三中心以及其衍生出的兩地四中心等，主要就是在同城雙活的基礎之上再增加一個災備中心，這個災備中心常態下是不接收流量的，只有發生地域級故障時纔會切換。
傳統的容災方案
重新梳理一下傳統的容災方案，對於同城容災或者同城雙活而言，優勢在於部署簡單，並且接入成本非常低；缺點在於僅提供同城保護，在GB/T 20988中只能達到1級能力。對於異地冷備而言，優勢同樣在於部署簡單，對業務侵入比較少，並且異地部署的災備能力相對而言會高一些，能夠達到2到5級；缺點在於冷備單元冗餘成本較高，造成一定的資源浪費，此外因爲災備單元常年不接流量，因此真正發生故障的時候切換是否可用是一個未知數。對於兩地三中心而言，其實就是同城雙活和異地冷備兩種方案的結合，其優勢就是上述兩個方案的優勢，缺點則是冷備中心成本浪費和地域級故障發生時不敢進行切換。
二、阿里雲異地多活解決方案
阿里雲異地多活架構
如上圖所示的是阿里雲異地多活整體架構。實際上，異地多活的本質是通過對業務做自頂向下的流量隔離來實現的。阿里雲將整個異地多活架構分爲三層，第一層是接入層，實現異地雙活首先需要爲業務制定一個分流策略，如按照地域或用戶維度分配流量，一旦定義好分流策略，即可在接入層實現流量拆分，屬於本單元的流量可以繼續向下透傳執行，如果不屬於則會將其轉入正確的單元。第二層是服務層，就是對外提供服務的業務系統，針對於提供能力的不同劃分爲了單元化服務、中心化服務和普通服務三種類型。第三層是數據層，這一層所需要解決的是數據庫所需要具備的雙向跨域同步能力、防循環能力，並且需要保障切流時的數據質量。
阿里雲針對OLTP和OLAP兩種業務場景對於多活架構方案進行了細化，接下來逐個介紹。
OLTP業務多活架構
針對於OLTP業務，阿里雲提供了一套相應的多活架構，其中包含了幾個關鍵要素。第一，多活配置，主要通過MSHA進行一站式多活配置，其負責制定流量劃分策略、決定哪些數據庫需要進行多活。第二，多活流量控制，主要根據既定規則通過MSFE進行分流，其負責流量識別、流量分發以及流量校正。第三，多活數據同步，主要是通過DTS實現，DTS本身是數據同步工具，其針對多活場景增加了很多新功能，如防循環、網絡優化和切流聯動等。第四，多活容災切換，也是通過MSHA實現，主要負責將規格下推到各層，並對多活切換之前的狀態進行全局檢查。第五，多活場景運維，通過DMS實現，多活場景下實現DDL變更和數據運維存在雙寫問題，並存在同步延遲的可能，因此執行DDL和DML變更的策略是不同的，DMS針對於多活場景進行了能力適配。
OLAP業務多活架構
OLAP業務多活架構與OLTP區別不大，要素也基本一樣，唯一不同在於在OLTP業務多活架構中在底層實現了雙向的數據同步，在OLAP業務多活架構中，則不建議做這樣的工作。主要有兩個原因，其一，跨地域數據同步的帶寬成本非常高，如果OLTP已經將數據同步了一份，那麼儘量選擇在雲內同步，而不是OLAP同步；其次，還需要保證數據一致性，在OLTP上同步了一次，如果在OLAP上還需要同步一次，那麼保證數據一致性就會比較困難。因此，阿里雲建議不在OLAP上做數據同步，而應該全部在OLTP上做，並且在雲內可以實現數據同步能力的補齊。
雙活典型架構：雙Region四AZ
上圖所示的是雙活典型架構，分爲兩個Region，每個Region裏面各有兩個AZ，首先具備AZ級別的容災能力，如果真的發生了地域級故障，再將Region級別的容災能力用起來。在這個架構下，MSFE以及具體業務系統等是跨AZ部署的，在雲內具備AZ級高可用。數據庫在AZ1和AZ2、AZ3和AZ4可以進行主備部署，底層通過DTS實現雙向同步。數據是四份副本冗餘，業務冗餘達到200%，每個AZ冗餘到達50%，但真正承接流量時可實現每個AZ只有25%，業務可以自行調配。對於計劃外的切換而言，可以達到分鐘級RTO。
多活中不同的服務類型
前面提到服務層分爲三種服務類型，第一種是單元化服務，這是在多活架構下主要面向的服務類型，比如淘寶買家的信息修改就是典型的單元化服務，其根據買家的用戶ID進行流量分流，在這個維度下，可以實現單元內封閉調用，不依賴於對端數據，而底層的數據同步只是在數據切換時確保對端數據是完整的，能夠將數據補齊的，這樣切換之後能夠讓業務直接運行。第二種是中心化服務，主要面向全局配置或者業務具有強中心讀寫要求的場景，如庫存扣減，不允許在多個地方同時扣減同個庫存，這種場景一定會訪問中心數據庫，底層通過單向同步來同步數據，這樣的服務提供的並不是多活能力，而是容災能力。第三種是普通服務，所針對的是如果業務按照某一個維度進行了流量劃分，那麼一些耦合的邊緣服務可能無法按照相同維度進行劃分，這類業務可能會選擇普通服務。普通服務能夠容忍同步延遲，也就是最終一致，但是無法接受訪問延遲，因此主要面向讀服務，不建議寫場景使用。
跨雲數據同步
上述三種服務類型在底層的數據同步方式不同，因此給出了兩種跨雲數據同步方式。第一種是COPY類型的數據同步方式，主要面向中心化服務和普通服務，數據是單向同步的，單元只可讀不可寫，同步任務配置通過白名單+DDL放行方式實現。第二種是UNIT類型的數據同步方式，主要面向單元化服務和普通服務，數據是雙向同步的，各單元均可讀寫，此時就需要通過事務表等解決防循環問題，並且通過全局Sequence避免衝突。
防循環&Sequence
阿里雲PolarDB和RDS數據庫等針對於防循環和Sequence兩個能力進行了實現。在防循環部分，主要提供了兩種方式，第一種是事務表方式，也就是業務在寫入數據庫的時候，即事務提交完成，生成Binlog，Binlog被DTS拿走並解析完成後會發現向目標單元DB寫入的時候會在事務表裏面產生一個自定義記錄，這樣一來在單元裏面落地的事務實際上除了原始業務邏輯之外還會多一個小Event。通過目標端的DTS解析之後就會發現Binlog裏面還多了一個事務操作，就會知道這個操作是來自於DTS的，而不是來自於業務系統的，因此可以將該操作過濾掉，進而放置數據循環。第二種是通過THREAD_ID的方式，這是AliSQL內核定製的優化功能，將原生MySQL內核的THREAD_ID從8字節改到了5字節，因此業務生成連接只能是0x00000到0xFFFFF之間，而高位則留給DTS連接使用，這樣中心DB就能夠區別兩類連接，Binlog會記錄所有的THREAD_ID，因此DTS也能夠很清晰地解析出來操作來自於業務還是DTS，如果來自業務就同步過去，如果來自DTS就中斷掉，從而達到防循環的功能。第一種方式對業務具有一定的侵入性，第二種則是完全原生的能力，對用戶或者內核沒有太大影響。
對於Sequence功能而言，其實就是在兩邊同時寫入數據，需要保證數據不能衝突。因此，阿里雲針對於PolarDB-X做了全局唯一Sequence的能力，在原生的DDL上面增加了標識去控制當前單元個數以及每個單元的Index。基於這種方式創建出來的表，以內步長爲10萬，單元數爲2舉例，產生結果如上圖所示，從而達到全局Sequence的能力。
多活場景數據保護
在多活場景下，和原生最大的區別就是不需要關注可用性，但是卻多了數據質量的問題，該問題在單數據中心場景下可能不容易發生，但是在多活場景下因爲業務需要雙寫，因此容易出現數據質量的衝突問題。歸根結底，所有的數據質量問題都是由於數據雙寫導致的，因此需要針對於這種場景制定一定的保護措施。阿里雲制定了三個維度的單元保護措施，第一個是日常態，針對接入層、應用層和數據層提供相應的方法多寫操作的多活分流規則進行路由邏輯校驗，如果非本單元流量，則在接入層和應用層將流量轉走，但如果在數據層，則直接阻塞掉。第二個是變更態，主要針對數據運維變更，比如批量數據訂正，阿里雲提供了事前檢查和事後補充的能力，在DMS上面針對於多活場景下的數據變更任務提前檢查變更情況，如果同步延遲很大則會被阻塞掉，降低了數據雙寫的概率，同時在變更前和變更後通過檢查保持數據的一致。第三個是切流態，是在數據多活切流過程中做的保護策略，包括了絕對禁寫、延遲禁寫、前鏡像匹配同步以及延遲檢查等功能。
多活切流流程
在多活切流時，首先會打開前鏡像匹配功能。一般認爲，在多活場景下業務寫入的數據比同步過來的數據更重要，因此需要保證業務寫入的數據不被同步的數據覆蓋掉，所以如果切流過程中，數據同步有延遲，爲了不覆蓋掉業務數據，則需要將Binlog裏面前鏡像拿出來拼到SQL裏面去執行。前鏡像匹配功能開啓之後會將新的流量分發規則在各層進行下發，在規則下發完成之後會開啓絕對禁寫的動作，在此過程中，所有參與切流的用戶流量是無法執行的。在禁寫過程中首先需要判斷三層規則是否全部收斂成功，其次還需要判斷每層內各個節點的規則是否收斂成功，最終目標是讓所有服務器上的規則保持一致，這樣才能保證不出現雙寫。上述條件滿足之後，解除絕對禁寫，開啓延遲禁寫，這一點可由用戶配置。當數據同步完成之後，解除禁寫和前鏡像匹配，切流過程至此完成。
異地多活價值總結
簡單總結下異地多活的價值。首先，多活本身是做容災的，但是現在來看異地多活已經不像是傳統容災那樣放置一個災備單元了。現在業務即容災，業務系統和容災系統緊密地連接到了一起。其次，業務連續性有了保障，爲業務提供了高可用能力。第三，爲業務的高速發展提供了支撐，在多活場景下劃分了很多原子單元，可以根據原子單元合理配比相關資源，達到最優效果，最終具有跨地域的水平擴展能力。第四，流量有效隔離，基於阿里雲的異地多活解決方案可以非常靈活地調配流量，可以按照不同維度設置規格，也可以按照不同的權重配比設置，實現流量大小的靈活調配，並可實現在最小單元內進行風險可控的技術試驗。第五，降本增效，傳統容災方案無法突破200%的冗餘成本問題，而通過三活、四活的方案可以實現冗餘成本小於200%。
用戶自行實施異地多活的難點
用戶自行實施異地多活所需面對很多難點，如流量管理難度高、數據同步策略複雜、容災切換數據質量保障難，以及多數據中心統一管控難度大等，這也是阿里巴巴將異地多活能力沉澱爲產品級解決方案的推動力。基於阿里雲的異地多活方案，用戶只需要關係如何對流量進行分割即可。