簡介：異地多活，顧名思義就是分布在異地多個站點同時對外提供服務(wù)，與傳統(tǒng)災(zāi)備最主要的區(qū)別是“多活”里所有站點都是同時在對外提供服務(wù)的。在業(yè)務(wù)不斷復(fù)雜化和容災(zāi)要求不斷嚴格化的今天，如何實現(xiàn)云原生的異地多活解決方案，成為了中大型企業(yè)不得不面對的挑戰(zhàn)。在第十一屆中國數(shù)據(jù)庫技術(shù)大會（DTCC2020）上，阿里云高級數(shù)據(jù)庫專家張鑫就為大家分享了阿里云云原生異地多活解決方案。

摘要：異地多活，顧名思義就是分布在異地多個站點同時對外提供服務(wù)，與傳統(tǒng)災(zāi)備最主要的區(qū)別是“多活”里所有站點都是同時在對外提供服務(wù)的。在業(yè)務(wù)不斷復(fù)雜化和容災(zāi)要求不斷嚴格化的今天，如何實現(xiàn)云原生的異地多活解決方案，成為了中大型企業(yè)不得不面對的挑戰(zhàn)。在第十一屆中國數(shù)據(jù)庫技術(shù)大會（DTCC2020）上，阿里云高級數(shù)據(jù)庫專家張鑫就為大家分享了阿里云云原生異地多活解決方案。

本文內(nèi)容根據(jù)演講錄音及PPT整理而成。

嘉賓介紹：

張鑫（花名：六金），阿里云高級數(shù)據(jù)庫專家，之前主要作為DBA支持阿里巴巴內(nèi)部包括交易、廣告等在內(nèi)的核心系統(tǒng)，近兩年轉(zhuǎn)戰(zhàn)專有云市場，面向大型政企客戶提供數(shù)據(jù)庫解決方案。

本次分享將主要分為三個方面：

容災(zāi)架構(gòu)分析

阿里云異地多活解決方案

異地多活客戶案例

一、容災(zāi)架構(gòu)分析

容災(zāi)必要性

異地多活本身是從容災(zāi)出發(fā)的，因此首先介紹一下容災(zāi)的必要性。生產(chǎn)系統(tǒng)可能會遇到三類故障，第一個是主機級故障，如單點負載過高、數(shù)據(jù)損壞等；第二類是機房級故障，如供電故障、機房網(wǎng)絡(luò)故障等；第三類是地域級故障，如自然災(zāi)害等。對于上述三類故障而言，顯然是地域級故障影響面最大，但發(fā)生概率最低，但對于主機級故障而言，卻并不一定發(fā)生概率低且影響面小。阿里巴巴對于自身多年來的故障類型做了梳理，發(fā)現(xiàn)隨著現(xiàn)在業(yè)務(wù)系統(tǒng)復(fù)雜度的增加，單點故障也可能會造成全局影響，而且當復(fù)雜度達到一定程度時，如果發(fā)生這種單點故障，排查和恢復(fù)都會非常困難，因此容災(zāi)能力成為了企業(yè)信息化建設(shè)的必選項。

容災(zāi)行業(yè)分析

從行業(yè)分析來看，容災(zāi)的市場還是比較可觀的。根據(jù)權(quán)威報告預(yù)測：在2020年全球容災(zāi)市場份額將達到115.9億美元，并且客戶群體非常廣泛，比如政府、金融、能源、互聯(lián)網(wǎng)、通信等，基本上只要有信息化系統(tǒng)就有容災(zāi)需求。阿里云目前擁有十萬家企業(yè)用戶和四十萬個數(shù)據(jù)庫實例，這些都需要容災(zāi)能力保障。而在國家層面，也具有嚴格的合規(guī)要求，尤其是現(xiàn)在大型的政企客戶都需參照《信息系統(tǒng)容災(zāi)恢復(fù)規(guī)范》GB/T 20988進行容災(zāi)建設(shè)。

容災(zāi)架構(gòu)演進

容災(zāi)架構(gòu)的演進主要分成幾個階段。同城容災(zāi)最為簡單，即在同一個地域內(nèi)有一個IDC并部署了業(yè)務(wù)，容災(zāi)時再部署一個機房備份系統(tǒng)和數(shù)據(jù)庫，在中間實現(xiàn)異步或者同步的數(shù)據(jù)同步，業(yè)務(wù)流量集中在一邊，另外一邊只做災(zāi)備。后來逐漸演進出了同城雙活，其借用了同城內(nèi)兩個數(shù)據(jù)中心地理距離比較近，網(wǎng)絡(luò)延遲較短的優(yōu)勢，可以將業(yè)務(wù)部署到兩端，因為物理距離較短，延遲等問題都可以接受。再往后就是異地雙活，即兩點三中心以及其衍生出的兩地四中心等，主要就是在同城雙活的基礎(chǔ)之上再增加一個災(zāi)備中心，這個災(zāi)備中心常態(tài)下是不接收流量的，只有發(fā)生地域級故障時才會切換。

傳統(tǒng)的容災(zāi)方案

重新梳理一下傳統(tǒng)的容災(zāi)方案，對于同城容災(zāi)或者同城雙活而言，優(yōu)勢在于部署簡單，并且接入成本非常低；缺點在于僅提供同城保護，在GB/T 20988中只能達到1級能力，因此對于大型客戶而言，無法選擇該方案。對于異地冷備而言，優(yōu)勢同樣在于部署簡單，對業(yè)務(wù)侵入比較少，并且異地部署的災(zāi)備能力相對而言會高一些，能夠達到2到5級；缺點在于冷備單元冗余成本較高，造成一定的資源浪費，此外因為災(zāi)備單元常年不接流量，因此真正發(fā)生故障的時候切換是否可用是一個未知數(shù)。對于兩地三中心而言，其實就是同城雙活和異地冷備兩種方案的結(jié)合，其優(yōu)勢就是上述兩個方案的優(yōu)勢，缺點則是冷備中心成本浪費和地域級故障發(fā)生時不敢進行切換。

二、阿里云異地多活解決方案

阿里云異地多活架構(gòu)

如上圖所示的是阿里云異地多活整體架構(gòu)。實際上，異地多活的本質(zhì)是通過對業(yè)務(wù)做自頂向下的流量隔離來實現(xiàn)的。阿里云將整個異地多活架構(gòu)分為三層，第一層是接入層，實現(xiàn)異地雙活首先需要為業(yè)務(wù)制定一個分流策略，如按照地域或用戶維度分配流量，一旦定義好分流策略，即可在接入層實現(xiàn)流量拆分，屬于本單元的流量可以繼續(xù)向下透傳執(zhí)行，如果不屬于則會將其轉(zhuǎn)入正確的單元。第二層是服務(wù)層，就是對外提供服務(wù)的業(yè)務(wù)系統(tǒng)，針對于提供能力的不同劃分為了單元化服務(wù)、中心化服務(wù)和普通服務(wù)三種類型。第三層是數(shù)據(jù)層，這一層所需要解決的是數(shù)據(jù)庫所需要具備的雙向跨域同步能力、防循環(huán)能力，并且需要保障切流時的數(shù)據(jù)質(zhì)量。

阿里云針對OLTP和OLAP兩種業(yè)務(wù)場景對于多活架構(gòu)方案進行了細化，接下來逐個介紹。

OLTP業(yè)務(wù)多活架構(gòu)

針對于OLTP業(yè)務(wù)，阿里云提供了一套相應(yīng)的多活架構(gòu)，其中包含了幾個關(guān)鍵要素。第一，多活配置，主要通過MSHA進行一站式多活配置，其負責制定流量劃分策略、決定哪些數(shù)據(jù)庫需要進行多活。第二，多活流量控制，主要根據(jù)既定規(guī)則通過MSFE進行分流，其負責流量識別、流量分發(fā)以及流量校正。第三，多活數(shù)據(jù)同步，主要是通過DTS實現(xiàn)，DTS本身是數(shù)據(jù)同步工具，其針對多活場景增加了很多新功能，如防循環(huán)、網(wǎng)絡(luò)優(yōu)化和切流聯(lián)動等。第四，多活容災(zāi)切換，也是通過MSHA實現(xiàn)，主要負責將規(guī)格下推到各層，并對多活切換之前的狀態(tài)進行全局檢查。第五，多活場景運維，通過DMS實現(xiàn)，多活場景下實現(xiàn)DDL變更和數(shù)據(jù)運維存在雙寫問題，并存在同步延遲的可能，因此執(zhí)行DDL和DML變更的策略是不同的，DMS針對于多活場景進行了能力適配。

OLAP業(yè)務(wù)多活架構(gòu)

OLAP業(yè)務(wù)多活架構(gòu)與OLTP區(qū)別不大，要素也基本一樣，唯一不同在于在OLTP業(yè)務(wù)多活架構(gòu)中在底層實現(xiàn)了雙向的數(shù)據(jù)同步，在OLAP業(yè)務(wù)多活架構(gòu)中，則不建議做這樣的工作。主要有兩個原因，其一，跨地域數(shù)據(jù)同步的帶寬成本非常高，如果OLTP已經(jīng)將數(shù)據(jù)同步了一份，那么盡量選擇在云內(nèi)同步，而不是OLAP同步；其次，還需要保證數(shù)據(jù)一致性，在OLTP上同步了一次，如果在OLAP上還需要同步一次，那么保證數(shù)據(jù)一致性就會比較困難。因此，阿里云建議不在OLAP上做數(shù)據(jù)同步，而應(yīng)該全部在OLTP上做，并且在云內(nèi)可以實現(xiàn)數(shù)據(jù)同步能力的補齊。

雙活典型架構(gòu)：雙Region四AZ

上圖所示的是雙活典型架構(gòu)，分為兩個Region，每個Region里面各有兩個AZ，首先具備AZ級別的容災(zāi)能力，如果真的發(fā)生了地域級故障，再將Region級別的容災(zāi)能力用起來。在這個架構(gòu)下，MSFE以及具體業(yè)務(wù)系統(tǒng)等是跨AZ部署的，在云內(nèi)具備AZ級高可用。數(shù)據(jù)庫在AZ1和AZ2、AZ3和AZ4可以進行主備部署，底層通過DTS實現(xiàn)雙向同步。數(shù)據(jù)是四份副本冗余，業(yè)務(wù)冗余達到200%，每個AZ冗余到達50%，但真正承接流量時可實現(xiàn)每個AZ只有25%，業(yè)務(wù)可以自行調(diào)配。對于計劃外的切換而言，可以達到分鐘級RTO。

多活中不同的服務(wù)類型

前面提到服務(wù)層分為三種服務(wù)類型，第一種是單元化服務(wù)，這是在多活架構(gòu)下主要面向的服務(wù)類型，比如淘寶買家的信息修改就是典型的單元化服務(wù)，其根據(jù)買家的用戶ID進行流量分流，在這個維度下，可以實現(xiàn)單元內(nèi)封閉調(diào)用，不依賴于對端數(shù)據(jù)，而底層的數(shù)據(jù)同步只是在數(shù)據(jù)切換時確保對端數(shù)據(jù)是完整的，能夠?qū)?shù)據(jù)補齊的，這樣切換之后能夠讓業(yè)務(wù)直接運行。第二種是中心化服務(wù)，主要面向全局配置或者業(yè)務(wù)具有強中心讀寫要求的場景，如庫存扣減，不允許在多個地方同時扣減同個庫存，這種場景一定會訪問中心數(shù)據(jù)庫，底層通過單向同步來同步數(shù)據(jù)，這樣的服務(wù)提供的并不是多活能力，而是容災(zāi)能力。第三種是普通服務(wù)，所針對的是如果業(yè)務(wù)按照某一個維度進行了流量劃分，那么一些耦合的邊緣服務(wù)可能無法按照相同維度進行劃分，這類業(yè)務(wù)可能會選擇普通服務(wù)，比如淘寶交易按照買家ID進行劃分，那么賣家就無法按照這一維度進行劃分。普通服務(wù)能夠容忍同步延遲，也就是最終一致，但是無法接受訪問延遲，因此主要面向讀服務(wù)，不建議寫場景使用。

跨云數(shù)據(jù)同步

上述三種服務(wù)類型在底層的數(shù)據(jù)同步方式不同，因此給出了兩種跨云數(shù)據(jù)同步方式。第一種是COPY類型的數(shù)據(jù)同步方式，主要面向中心化服務(wù)和普通服務(wù)，數(shù)據(jù)是單向同步的，單元只可讀不可寫，同步任務(wù)配置通過白名單+DDL放行方式實現(xiàn)。第二種是UNIT類型的數(shù)據(jù)同步方式，主要面向單元化服務(wù)和普通服務(wù)，數(shù)據(jù)是雙向同步的，各單元均可讀寫，此時就需要通過事務(wù)表等解決防循環(huán)問題，并且通過全局Sequence避免沖突。

防循環(huán)&Sequence

阿里云POLARDB和RDS數(shù)據(jù)庫等針對于防循環(huán)和Sequence兩個能力進行了實現(xiàn)。在防循環(huán)部分，主要提供了兩種方式，第一種是事務(wù)表方式，也就是業(yè)務(wù)在寫入數(shù)據(jù)庫的時候，即事務(wù)提交完成，生成Binlog，Binlog被DTS拿走并解析完成后會發(fā)現(xiàn)向目標單元DB寫入的時候會在事務(wù)表里面產(chǎn)生一個自定義記錄，這樣一來在單元里面落地的事務(wù)實際上除了原始業(yè)務(wù)邏輯之外還會多一個小Event。通過目標端的DTS解析之后就會發(fā)現(xiàn)Binlog里面還多了一個事務(wù)操作，就會知道這個操作是來自于DTS的，而不是來自于業(yè)務(wù)系統(tǒng)的，因此可以將該操作過濾掉，進而放置數(shù)據(jù)循環(huán)。第二種是通過THREAD_ID的方式，這是AliSQL內(nèi)核定制的優(yōu)化功能，將原生MySQL內(nèi)核的THREAD_ID從8字節(jié)改到了5字節(jié)，因此業(yè)務(wù)生成連接只能是0x00000到0xFFFFF之間，而高位則留給DTS連接使用，這樣中心DB就能夠區(qū)別兩類連接，Binlog會記錄所有的THREAD_ID，因此DTS也能夠很清晰地解析出來操作來自于業(yè)務(wù)還是DTS，如果來自業(yè)務(wù)就同步過去，如果來自DTS就中斷掉，從而達到防循環(huán)的功能。第一種方式對業(yè)務(wù)具有一定的侵入性，第二種則是完全原生的能力，對用戶或者內(nèi)核沒有太大影響。

對于Sequence功能而言，其實就是在兩邊同時寫入數(shù)據(jù)，需要保證數(shù)據(jù)不能沖突。因此，阿里云針對于POLARDB-X做了全局唯一Sequence的能力，在原生的DDL上面增加了標識去控制當前單元個數(shù)以及每個單元的Index?；谶@種方式創(chuàng)建出來的表，以內(nèi)步長為10萬，單元數(shù)為2舉例，產(chǎn)生結(jié)果如上圖所示，從而達到全局Sequence的能力。

多活場景數(shù)據(jù)保護

在多活場景下，和原生最大的區(qū)別就是不需要關(guān)注可用性，但是卻多了數(shù)據(jù)質(zhì)量的問題，該問題在單數(shù)據(jù)中心場景下可能不容易發(fā)生，但是在多活場景下因為業(yè)務(wù)需要雙寫，因此容易出現(xiàn)數(shù)據(jù)質(zhì)量的沖突問題。歸根結(jié)底，所有的數(shù)據(jù)質(zhì)量問題都是由于數(shù)據(jù)雙寫導(dǎo)致的，因此需要針對于這種場景制定一定的保護措施。阿里云制定了三個維度的單元保護措施，第一個是日常態(tài)，針對接入層、應(yīng)用層和數(shù)據(jù)層提供相應(yīng)的方法多寫操作的多活分流規(guī)則進行路由邏輯校驗，如果非本單元流量，則在接入層和應(yīng)用層將流量轉(zhuǎn)走，但如果在數(shù)據(jù)層，則直接阻塞掉。第二個是變更態(tài)，主要針對數(shù)據(jù)運維變更，比如批量數(shù)據(jù)訂正，阿里云提供了事前檢查和事后補充的能力，在DMS上面針對于多活場景下的數(shù)據(jù)變更任務(wù)提前檢查變更情況，如果同步延遲很大則會被阻塞掉，降低了數(shù)據(jù)雙寫的概率，同時在變更前和變更后通過檢查保持數(shù)據(jù)的一致。第三個是切流態(tài)，是在數(shù)據(jù)多活切流過程中做的保護策略，包括了絕對禁寫、延遲禁寫、前鏡像匹配同步以及延遲檢查等功能。

多活切流流程

在多活切流時，首先會打開前鏡像匹配功能。一般認為，在多活場景下業(yè)務(wù)寫入的數(shù)據(jù)比同步過來的數(shù)據(jù)更重要，因此需要保證業(yè)務(wù)寫入的數(shù)據(jù)不被同步的數(shù)據(jù)覆蓋掉，所以如果切流過程中，數(shù)據(jù)同步有延遲，為了不覆蓋掉業(yè)務(wù)數(shù)據(jù)，則需要將Binlog里面前鏡像拿出來拼到SQL里面去執(zhí)行。前鏡像匹配功能開啟之后會將新的流量分發(fā)規(guī)則在各層進行下發(fā)，在規(guī)則下發(fā)完成之后會開啟絕對禁寫的動作，在此過程中，所有參與切流的用戶流量是無法執(zhí)行的。在禁寫過程中首先需要判斷三層規(guī)則是否全部收斂成功，其次還需要判斷每層內(nèi)各個節(jié)點的規(guī)則是否收斂成功，最終目標是讓所有服務(wù)器上的規(guī)則保持一致，這樣才能保證不出現(xiàn)雙寫。上述條件滿足之后，解除絕對禁寫，開啟延遲禁寫，這一點可由用戶配置。當數(shù)據(jù)同步完成之后，解除禁寫和前鏡像匹配，切流過程至此完成。

異地多活價值總結(jié)

簡單總結(jié)下異地多活的價值。首先，多活本身是做容災(zāi)的，但是現(xiàn)在來看異地多活已經(jīng)不像是傳統(tǒng)容災(zāi)那樣放置一個災(zāi)備單元了。現(xiàn)在業(yè)務(wù)即容災(zāi)，業(yè)務(wù)系統(tǒng)和容災(zāi)系統(tǒng)緊密地連接到了一起。其次，業(yè)務(wù)連續(xù)性有了保障，為業(yè)務(wù)提供了高可用能力。第三，為業(yè)務(wù)的高速發(fā)展提供了支撐，在多活場景下劃分了很多原子單元，可以根據(jù)原子單元合理配比相關(guān)資源，達到最優(yōu)效果，最終具有跨地域的水平擴展能力。第四，流量有效隔離，基于阿里云的異地多活解決方案可以非常靈活地調(diào)配流量，可以按照不同維度設(shè)置規(guī)格，也可以按照不同的權(quán)重配比設(shè)置，實現(xiàn)流量大小的靈活調(diào)配，并可實現(xiàn)在最小單元內(nèi)進行風險可控的技術(shù)試驗。第五，降本增效，傳統(tǒng)容災(zāi)方案無法突破200%的冗余成本問題，而通過三活、四活的方案可以實現(xiàn)冗余成本小于200%。

用戶自行實施異地多活的難點

用戶自行實施異地多活所需面對很多難點，如流量管理難度高、數(shù)據(jù)同步策略復(fù)雜、容災(zāi)切換數(shù)據(jù)質(zhì)量保障難，以及多數(shù)據(jù)中心統(tǒng)一管控難度大等，這也是阿里巴巴將異地多活能力沉淀為產(chǎn)品級解決方案的推動力。基于阿里云的異地多活方案，用戶只需要關(guān)系如何對流量進行分割即可。

阿里云云原生方案優(yōu)勢

目前能夠?qū)崿F(xiàn)產(chǎn)品級異地多活能力的廠商極少，阿里云經(jīng)過8年的積累和沉淀，在異地多活的云原生方案上具有諸多優(yōu)勢。

三、異地多活客戶案例

客戶案例-某稅務(wù)核心系統(tǒng)

某稅務(wù)核心系統(tǒng)的異地多活方案也是按照三層架構(gòu)實現(xiàn)的，在接入層，支持按照兩個維度流量拆分，即省份和自然人檔案號。在服務(wù)層利用CSB產(chǎn)品實現(xiàn)普通服務(wù)的跨云調(diào)用。在數(shù)據(jù)層，針對不同服務(wù)類型實施不同容災(zāi)級別的數(shù)據(jù)同步。最終實現(xiàn)了兩個維度的多活，秒級切換能力，達到了國標6級效果，因為基于兩單元接流，因此在成本上具有優(yōu)勢，并且具有灰度放量能力。

客戶案例-某運營商客服系統(tǒng)

某運營商客服系統(tǒng)實現(xiàn)了按省份分流能力，即按照DNS的地域分流接入南北兩個中心，接入層按照路由規(guī)則進行判斷和糾錯，在業(yè)務(wù)層對于客戶原有系統(tǒng)進行了適配改造，實現(xiàn)了雙中心的服務(wù)同步。在數(shù)據(jù)層，則通過POLARDB-X和DTS實現(xiàn)雙向數(shù)據(jù)同步。最終使得該運營商客服系統(tǒng)的多個業(yè)務(wù)按地域多活分流，在多次容災(zāi)演練中，可以完成秒級切換，并保障了數(shù)據(jù)0丟失。此外，由于常態(tài)由兩個單元承載業(yè)務(wù)流量，因此成本也有所降低。

點擊這里下載本場演講PPT

相關(guān)閱讀

【內(nèi)含干貨PPT下載】DTCC 2020 | 阿里云葉正盛：數(shù)據(jù)庫2025
https://developer.aliyun.com/article/780725

【內(nèi)含干貨PPT下載】DTCC 2020 | 阿里云趙殿奎：PolarDB的Oracle平滑遷移之路
https://developer.aliyun.com/article/780749

【內(nèi)含干貨PPT下載】DTCC 2020 | 阿里云朱潔：NoSQL最新技術(shù)發(fā)展趨勢
https://developer.aliyun.com/article/780746

【內(nèi)含干貨PPT下載】DTCC 2020 | 阿里云王濤：阿里巴巴電商數(shù)據(jù)庫上云實踐
https://developer.aliyun.com/article/781001

DTCC 2020 | 阿里云梁高中：DAS之基于Workload的全局自動優(yōu)化實踐
https://developer.aliyun.com/article/781036

【內(nèi)含干貨PPT下載】DTCC 2020 | 阿里云程實：云原生時代的數(shù)據(jù)庫管理
https://developer.aliyun.com/article/780992

【內(nèi)含干貨PPT下載】DTCC 2020 | 阿里云吉劍南：在線分析進入Fast Data時代的關(guān)鍵技術(shù)解讀
https://developer.aliyun.com/article/780747

原文鏈接：https://developer.aliyun.com/article/781031?

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的DTCC 2020 | 阿里云张鑫：阿里云云原生异地多活解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。