在異地多活的實(shí)現(xiàn)上，數(shù)據(jù)能夠在三個(gè)及以上中心間進(jìn)行雙向同步，才是解決真正異地多活的核心技術(shù)所在。本文基于三中心且跨海外的場(chǎng)景，分享一種多中心容災(zāi)架構(gòu)及實(shí)現(xiàn)方式，介紹幾種分布式ID生成算法，以及在數(shù)據(jù)同步上最終一致性的實(shí)現(xiàn)過(guò)程。

一、背景

為什么稱之為真正的異地多活？異地多活已經(jīng)不是什么新鮮詞，但似乎一直都沒(méi)有實(shí)現(xiàn)真正意義上的異地多活。一般有兩種形式：一種是應(yīng)用部署在同城兩地或多地，數(shù)據(jù)庫(kù)一寫(xiě)多讀（主要是為了保證數(shù)據(jù)一致性），當(dāng)主寫(xiě)庫(kù)掛掉，再切換到備庫(kù)上；另一種是單元化服務(wù)，各個(gè)單元的數(shù)據(jù)并不是全量數(shù)據(jù)，一個(gè)單元掛掉，并不能切換到其他單元。目前還能看到雙中心的形式，兩個(gè)中心都是全量數(shù)據(jù)，但雙跟多還是有很大差距的，這里其實(shí)主要受限于數(shù)據(jù)同步能力，數(shù)據(jù)能夠在3個(gè)及以上中心間進(jìn)行雙向同步，才是解決真正異地多活的核心技術(shù)所在。

提到數(shù)據(jù)同步，這里不得不提一下DTS(Data Transmission Service)，最初阿里的DTS并沒(méi)有雙向同步的能力，后來(lái)有了云上版本后，也只限于兩個(gè)數(shù)據(jù)庫(kù)之間的雙向同步，做不到A-B-C這種形式，所以我們自研了數(shù)據(jù)同步組件，雖然不想重復(fù)造輪子，但也是沒(méi)辦法，后面會(huì)介紹一些實(shí)現(xiàn)細(xì)節(jié)。

再談?wù)劄槭裁匆龆嘀行娜轂?zāi)，以我所在的CDN&視頻云團(tuán)隊(duì)為例，首先是海外業(yè)務(wù)的需要，為了能夠讓海外用戶就近訪問(wèn)我們的服務(wù)，我們需要提供一個(gè)海外中心。但大多數(shù)業(yè)務(wù)還都是以國(guó)內(nèi)為主的，所以國(guó)內(nèi)要建雙中心，防止核心庫(kù)掛掉整個(gè)管控就都掛掉了。同時(shí)海外的環(huán)境比較復(fù)雜，一旦海外中心掛掉了，還可以用國(guó)內(nèi)中心頂上。國(guó)內(nèi)的雙中心還有個(gè)非常大的好處是可以通過(guò)一些路由策略，分散單中心系統(tǒng)的壓力。這種三個(gè)中心且跨海外的場(chǎng)景，應(yīng)該是目前異地多活最難實(shí)現(xiàn)的了。

二、系統(tǒng)CAP

面對(duì)這種全球性跨地域的分布式系統(tǒng)，我們不得不談到CAP理論，為了能夠多中心全量數(shù)據(jù)提供服務(wù)，Partition tolerance（分區(qū)容錯(cuò)性）是必須要解決的，但是根據(jù)CAP的理論，Consistency（一致性）和Availability（可用性）就只能滿足一個(gè)。對(duì)于線上應(yīng)用，可用性自不用說(shuō)了，那面對(duì)這樣一個(gè)問(wèn)題，最終一致性是最好的選擇。

三、設(shè)計(jì)原則

1、數(shù)據(jù)分區(qū)

選擇一個(gè)數(shù)據(jù)維度來(lái)做數(shù)據(jù)切片，進(jìn)而實(shí)現(xiàn)業(yè)務(wù)可以分開(kāi)部署在不同的數(shù)據(jù)中心。主鍵需要設(shè)計(jì)成分布式ID形式，這樣當(dāng)進(jìn)行數(shù)據(jù)同步時(shí)，不會(huì)造成主鍵沖突。

下面介紹幾個(gè)分布式ID生成算法。

1）SnowFlake算法

① 算法說(shuō)明

+--------------------------------------------------------------------------+| 1 Bit Unused | 41 Bit Timestamp |  10 Bit NodeId  |   12 Bit Sequence Id |+--------------------------------------------------------------------------+ 

② 算法總結(jié)

③ 適用場(chǎng)景

一般的非Web應(yīng)用程序的int64類型的Id都可以使用。

為什么說(shuō)非Web應(yīng)用，Web應(yīng)用為什么不可以用呢，因?yàn)镴avaScript支持的最大整型就是53位，超過(guò)這個(gè)位數(shù)，JavaScript將丟失精度。

2）RainDrop算法

① 算法說(shuō)明

+--------------------------------------------------------------------------+| 11 Bit Unused | 32 Bit Timestamp |  7 Bit NodeId  |   14 Bit Sequence Id |+--------------------------------------------------------------------------+

 ② 算法總結(jié)

 ③ 適用場(chǎng)景

一般的Web應(yīng)用程序的int64類型的Id都基本夠用。

3）分區(qū)獨(dú)立分配算法

① 算法說(shuō)明

通過(guò)將Id分段分配給不同單元獨(dú)立管理。同一個(gè)單元的不同機(jī)器再通過(guò)共享redis進(jìn)行單元內(nèi)的集中分配。

相當(dāng)于每個(gè)單元預(yù)先分配了一批Id，然后再由各個(gè)單元內(nèi)進(jìn)行集中式分配。

比如int32的范圍從-2147483648到2147483647，Id使用范圍[1,2100000000)，前兩位表示region，則每個(gè)region支持100000000（一億）個(gè)資源，即Id組成格式可以表示為[0-20][0-99999999]。

即int32位可以支持20個(gè)單元，每個(gè)單元支持一億個(gè)Id。

② 算法總結(jié)

③ 適用場(chǎng)景

適用于int32類型的Id分配，單個(gè)區(qū)域內(nèi)容量上限可評(píng)估的業(yè)務(wù)使用。

4）集中式分配算法

① 算法說(shuō)明

集中式可以是Redis，也可以是ZooKeeper，也可以利用數(shù)據(jù)庫(kù)的自增Id集中分配。

② 算法總結(jié)

③ 適用場(chǎng)景

具備可靠的中心服務(wù)的場(chǎng)景可以選用，其他int32類型無(wú)法使用分區(qū)獨(dú)立分配的業(yè)務(wù)場(chǎng)景。

總結(jié)

每一種分配算法都有各自的適用場(chǎng)景，需要根據(jù)業(yè)務(wù)需求選擇合適的分配算法。主要需要考慮幾個(gè)因素：

• Id類型是int64還是int32。

• 業(yè)務(wù)容量以及并發(fā)量需求。

• 是否需要與JavaScript交互。

2、中心封閉

盡量讓調(diào)用發(fā)生在本中心，盡量避免跨數(shù)據(jù)中心的調(diào)用，一方面為了用戶體驗(yàn)，本地調(diào)用RT更短，另一方面防止同一個(gè)數(shù)據(jù)在兩個(gè)中心同時(shí)寫(xiě)入造成數(shù)據(jù)沖突覆蓋。一般可以選擇一種或多種路由方式，如ADNS根據(jù)地域路由，通過(guò)Tengine根據(jù)用戶屬性路由，或者通過(guò)sidecar方式進(jìn)行路由，具體實(shí)現(xiàn)方式這里就不展開(kāi)說(shuō)了。

3、最終一致性

前面兩種其實(shí)就是為了最終一致性做鋪墊，因?yàn)閿?shù)據(jù)同步是犧牲了一部分實(shí)時(shí)的性能，所以我們需要做數(shù)據(jù)分區(qū)，做中心封閉，這樣才能保證用戶請(qǐng)求的及時(shí)響應(yīng)和數(shù)據(jù)的實(shí)時(shí)準(zhǔn)確性。

前面提到了由于DTS支持的并不是很完善，所以我基于DRC（一個(gè)阿里內(nèi)部數(shù)據(jù)訂閱組件，類似canal）自己實(shí)現(xiàn)了數(shù)據(jù)同步的能力，下面介紹一下實(shí)現(xiàn)一致性的過(guò)程，中間也走了一些彎路。

1）順序接收DRC消息

為了保證對(duì)于DRC消息順序的接收，首先想到的是采用單機(jī)消費(fèi)的方式，而單機(jī)帶來(lái)的問(wèn)題是數(shù)據(jù)傳輸效率慢。針對(duì)這個(gè)問(wèn)題，涉及到并發(fā)的能力。大家可能會(huì)想到基于表級(jí)別的并發(fā)，但是如果單表數(shù)據(jù)變更大，同樣有性能瓶頸。這里我們實(shí)現(xiàn)了主鍵級(jí)別的并發(fā)能力，也就是說(shuō)在同一主鍵上，我們嚴(yán)格保序，不同主鍵之間可以并發(fā)同步，將并發(fā)能力又提高了N個(gè)數(shù)量級(jí)。

同時(shí)單機(jī)消費(fèi)的第二個(gè)問(wèn)題就是單點(diǎn)。所以我們要實(shí)現(xiàn)Failover。這里我們采用Raft協(xié)議進(jìn)行多機(jī)選主以及對(duì)主的請(qǐng)求。當(dāng)單機(jī)掛掉之后，其余的機(jī)器會(huì)自動(dòng)選出新的Leader執(zhí)行同步任務(wù)。

2）消息跨單元傳輸

為了很好的支持跨單元數(shù)據(jù)同步，我們采用了MNS（阿里云消息服務(wù)），MNS本身是個(gè)分布式的組件，無(wú)法滿足消息的順序性。起初為了保證強(qiáng)一致性，我采用消息染色與還原的方式，具體實(shí)現(xiàn)見(jiàn)下圖：

通過(guò)實(shí)踐我們發(fā)現(xiàn)，這種客戶端排序并不可靠，我們的系統(tǒng)不可能無(wú)限去等待一個(gè)消息的，這里涉及到最終一致性的問(wèn)題，在第3點(diǎn)中繼續(xù)探討。其實(shí)對(duì)于順序消息，RocketMQ是有順序消息的，但是RocketMQ目前還沒(méi)有實(shí)現(xiàn)跨單元的能力，而單純的就數(shù)據(jù)同步而言，我們只要保證最終一致性就可以了，沒(méi)有必要為了保證強(qiáng)一致性而犧牲性能。同時(shí)MNS消息如果沒(méi)有消費(fèi)成功，消息是不會(huì)丟掉的，只有我們?nèi)ワ@示的刪除消息，消息才會(huì)丟，所以最終這個(gè)消息一定會(huì)到來(lái)。

3）最終一致性

既然MNS無(wú)法保證強(qiáng)順序，而我們做的是數(shù)據(jù)同步，只要能夠保證最終一致性就可以了。2012年CAP理論提出者Eric Brewer撰文回顧C(jī)AP時(shí)也提到，C和A并不是完全互斥，建議大家使用CRDT來(lái)保障一致性。CRDT(Conflict-Free Replicated Data Type)是各種基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)最終一致算法的理論總結(jié)，能根據(jù)一定的規(guī)則自動(dòng)合并，解決沖突，達(dá)到強(qiáng)最終一致的效果。通過(guò)查閱相關(guān)資料，我們了解到CRDT要求我們?cè)跀?shù)據(jù)同步的時(shí)候要滿足交換律、結(jié)合律和冪等律。如果操作本身滿足以上三律，merge操作僅需要對(duì)update操作進(jìn)行回放即可，這種形式稱為op-based CRDT，如果操作本身不滿足，而通過(guò)附帶額外元信息能夠讓操作滿足以上三律，這種形式稱為state-based CRDT。

通過(guò)DRC的拆解，數(shù)據(jù)庫(kù)操作有三種：insert、update、delete，這三種操作不管哪兩種操作都是不能滿足交換律的，會(huì)產(chǎn)生沖突，所以我們?cè)诓l(fā)級(jí)別（主鍵）加上額外信息，這里我們采用序號(hào)，也就是2中提到的染色的過(guò)程，這個(gè)過(guò)程是保留的。而主鍵之間是并發(fā)的，沒(méi)有順序而言。當(dāng)接收消息的時(shí)候我們并不保證強(qiáng)順序，采用LWW（Last Write Wins）的方式，也就是說(shuō)我們執(zhí)行當(dāng)前的SQL而放棄前面的SQL，這樣我們就不用考慮交換的問(wèn)題。同時(shí)我們會(huì)根據(jù)消息的唯一性（實(shí)例+單元+數(shù)據(jù)庫(kù)+MD5(SQL)）對(duì)每個(gè)消息做冪等，保證每個(gè)SQL都不會(huì)重復(fù)執(zhí)行。而對(duì)于結(jié)合律，我們需要對(duì)每個(gè)操作單獨(dú)分析。

• insert

insert是不滿足結(jié)合律的，可能會(huì)有主鍵沖突，我們把insert語(yǔ)句變更insert ignore，而收到insert操作說(shuō)明之前并不存在這樣一條記錄，或者前面有delete操作。而delete操作可能還沒(méi)有到。這時(shí)insert ignore操作返回結(jié)果是0，但這次的insert數(shù)據(jù)可能跟已有的記錄內(nèi)容并不一致，所以這里我們將這個(gè)insert操作轉(zhuǎn)換為update 操作再執(zhí)行一次。

• update

update操作天然滿足結(jié)合律。但是這里又要考慮一種特殊情況，那就是執(zhí)行結(jié)果為0。這說(shuō)明此語(yǔ)句之前一定存在一個(gè)insert語(yǔ)句，但這個(gè)語(yǔ)句我們還沒(méi)有收到。這時(shí)我們需要利用這條語(yǔ)句中的數(shù)據(jù)將update語(yǔ)句轉(zhuǎn)成insert再重新執(zhí)行一次。

• delete

delete也是天然滿足結(jié)合律的，而無(wú)論之前都有什么操作，只要執(zhí)行就好了。

在insert和update操作里面，都有一個(gè)轉(zhuǎn)換的過(guò)程，而這里有個(gè)前提，那就是從DRC拿到的變更數(shù)據(jù)每一條都是全字段的。可能有人會(huì)說(shuō)這里的轉(zhuǎn)換可以用replace into替換，為什么沒(méi)有使用replace into呢，首先由于順序錯(cuò)亂的情況畢竟是少數(shù)，而且我們并不單純復(fù)制數(shù)據(jù)，同時(shí)也是在復(fù)制操作，而對(duì)于DRC來(lái)說(shuō)，replace into操作會(huì)被解析為update或insert。這樣無(wú)法保證消息唯一性，也無(wú)法做到防循環(huán)廣播，所以并不推薦。我們看看下面的流程圖也許會(huì)更清晰些：

四、容災(zāi)架構(gòu)

根據(jù)上面的介紹，我們來(lái)看下多中心容災(zāi)架構(gòu)的形態(tài)，這里用了兩級(jí)調(diào)度來(lái)保證中心封閉，同時(shí)利用自研的同步組件進(jìn)行多中心雙向同步。我們還可以制定一些快恢策略，例如快速摘掉一個(gè)中心。同時(shí)還有一些細(xì)節(jié)需要考慮，例如在摘掉一個(gè)中心的過(guò)程中，在摘掉的中心數(shù)據(jù)還沒(méi)有同步到其他中心的過(guò)程中，應(yīng)該禁掉寫(xiě)操作，防止短時(shí)間出現(xiàn)雙寫(xiě)的情況，由于我們同步的時(shí)間都是毫秒級(jí)的，所以影響很小。

五、結(jié)束語(yǔ)

架構(gòu)需要不斷的演進(jìn)，到底哪種更適合你還需要具體來(lái)看，上述的多中心架構(gòu)及實(shí)現(xiàn)方式歡迎大家來(lái)討論。

我們的數(shù)據(jù)同步組件hera-dts已在BU內(nèi)部進(jìn)行使用，數(shù)據(jù)同步的邏輯還是比較復(fù)雜的，尤其是實(shí)現(xiàn)雙向同步，其中涉及到斷點(diǎn)續(xù)傳、Failover、防丟數(shù)據(jù)、防消息重發(fā)、雙向同步中防循環(huán)復(fù)制等非常多的細(xì)節(jié)問(wèn)題。我們的同步組件也是經(jīng)歷了一段時(shí)間的優(yōu)化才達(dá)到穩(wěn)定的版本。