摘要：?MongoDB云上災(zāi)備BLS產(chǎn)品正式發(fā)布

1. 背景

??當(dāng)前的數(shù)據(jù)庫系統(tǒng)生態(tài)中，大部分系統(tǒng)都支持多個(gè)節(jié)點(diǎn)實(shí)例間的數(shù)據(jù)同步機(jī)制 ，如Mysql Master/Slave主從同步，Redis AOF主從同步等，MongoDB更是支持3節(jié)點(diǎn)(及以上)ReplicaSet同步，上述機(jī)制很好的支撐了一個(gè)邏輯單元的數(shù)據(jù)冗余及HA。
??跨邏輯單元(3節(jié)點(diǎn)實(shí)例、主從實(shí)例)，甚至跨單元、跨數(shù)據(jù)中心的數(shù)據(jù)同步，在業(yè)務(wù)層有時(shí)候就顯得很重要，可以支持同城多機(jī)房的負(fù)載均衡，多機(jī)房的互備，甚至是異地多數(shù)據(jù)中心容災(zāi)(比如 光纖被挖斷、地震等小概率事件)和多活。
??基于以上背景，云數(shù)據(jù)庫MongoDB版本正式推出MongoDB實(shí)例間的雙向同步產(chǎn)品“MongoDB云上災(zāi)備”（也稱BLS），助力企業(yè)快速復(fù)制阿里巴巴異地災(zāi)備、多活架構(gòu)。
??產(chǎn)品地址

2. 產(chǎn)品介紹

??“MongoDB云上災(zāi)備”通過從源數(shù)據(jù)庫拉取Oplog（Operations Log）數(shù)據(jù)（其是MongoDB的日志，所有對(duì)數(shù)據(jù)庫的修改操作都會(huì)保存到oplog中），然后將其傳輸?shù)侥康臄?shù)據(jù)庫進(jìn)行回放實(shí)現(xiàn)復(fù)制的目的。我們通過構(gòu)造兩條復(fù)制鏈路實(shí)現(xiàn)雙向同步的功能，基于此，可以實(shí)現(xiàn)災(zāi)備和多活的功能。
??上圖給出了整體復(fù)制同步的流程。目前，“MongoDB云上災(zāi)備”支持的源、目的數(shù)據(jù)庫類型為ReplicaSet副本集，Sharding模式即將上線，不支持單節(jié)點(diǎn)模式。為了減緩主節(jié)點(diǎn)的壓力，系統(tǒng)從備（Secondary）上拉取Oplog。

全量加增量

??同步模型采用全量+增量的方式：在創(chuàng)建時(shí)會(huì)對(duì)源數(shù)據(jù)庫進(jìn)行全量同步，后續(xù)的修改通過增量來同步。

雙活以及多活模型

??由于復(fù)制是異步模式，所以對(duì)于雙活/多活模式，由用戶保證不會(huì)對(duì)同一個(gè)唯一鍵同時(shí)修改，因?yàn)橥瑫r(shí)修改將可能導(dǎo)致數(shù)據(jù)錯(cuò)亂。目前沖突策略可以為覆蓋或者忽略。后續(xù)將會(huì)上線校驗(yàn)程序，在用戶操作相同唯一鍵時(shí)提供接口報(bào)錯(cuò)。

高效性保證

??同步延遲因地域和網(wǎng)絡(luò)不同而不同，理論TPS能夠接近20萬（每秒傳輸20萬條oplog）。為了保證批量傳輸?shù)母咝?，?shù)據(jù)發(fā)送存在緩存機(jī)制，所以少量數(shù)據(jù)的同步時(shí)延可能超過5秒。

• 源數(shù)據(jù)庫并行拉取，解決沖突依賴

• 并行發(fā)往Kafka通道

• 目的端在解決依賴的同時(shí)并行寫入數(shù)據(jù)庫

環(huán)形復(fù)制

??為了防止環(huán)形復(fù)制（數(shù)據(jù)從源復(fù)制到目的，又從目的復(fù)制到源），在Oplog日志中打入gid解決該問題。

可靠性傳輸

??支持?jǐn)帱c(diǎn)續(xù)傳，實(shí)例重啟時(shí)數(shù)據(jù)同步不受影響。

高可用

??鏈路同步具有高可用性，如果同步進(jìn)程掛掉，會(huì)有備進(jìn)程啟動(dòng)接管服務(wù)。

限制說明

• DDL語句同步暫未開放，所以如果修改了源、目的數(shù)據(jù)的索引操作，無法同步。

• 目的數(shù)據(jù)庫需要?jiǎng)?chuàng)建，暫不支持在2個(gè)已有MongoDB實(shí)例之間直接搭通道。

• 當(dāng)前只支持雙活功能(2個(gè)MongoDB實(shí)例之間同步數(shù)據(jù))，后續(xù)會(huì)上線多活功能(多個(gè)MongoDB實(shí)例之間同步數(shù)據(jù))。

3. 架構(gòu)

??在“MongoDB云上災(zāi)備”產(chǎn)品中，主要有3大組件：

• BLS Manager。中心控制模塊，負(fù)責(zé)Collector、Receiver的調(diào)度、監(jiān)控等任務(wù)。

• BLS Collector。數(shù)據(jù)采集模塊，負(fù)責(zé)從源MongoDB數(shù)據(jù)庫拉取Oplog數(shù)據(jù)后發(fā)送到Kafka通道。

• BLS Receiver。數(shù)據(jù)回放模塊，負(fù)責(zé)從Kafka通道中獲取數(shù)據(jù)，然后寫入目的MongoDB數(shù)據(jù)庫。

下圖展示了系統(tǒng)的整體架構(gòu)圖。

4. 用戶使用案例

??高德地圖 App是國內(nèi)首屈一指的地圖及導(dǎo)航應(yīng)用，阿里云MongoDB數(shù)據(jù)庫服務(wù)為該應(yīng)用提供了部分功能的存儲(chǔ)支撐，存儲(chǔ)億級(jí)別數(shù)據(jù)?，F(xiàn)在高德使用國內(nèi)三中心的策略，通過地理位置等信息路由最近中心提升服務(wù)質(zhì)量，業(yè)務(wù)方(高德地圖)通過用戶路由到三個(gè)城市數(shù)據(jù)中心，如下圖所示，機(jī)房數(shù)據(jù)之間無依賴計(jì)算。數(shù)據(jù)在不同中心的同步通過“MongoDB云上災(zāi)備”產(chǎn)品實(shí)現(xiàn)。

??這三個(gè)城市地理上從北到南橫跨了整個(gè)中國 ，這對(duì)多數(shù)據(jù)中心如何做好復(fù)制、容災(zāi)提出了挑戰(zhàn)，如果某個(gè)地域的機(jī)房、網(wǎng)絡(luò)出現(xiàn)問題，可以平滑的將流量切換到另一個(gè)地方，做到用戶幾乎無感知？
??目前策略是，拓?fù)洳捎脵C(jī)房?jī)蓛苫ヂ?lián)方式，每個(gè)機(jī)房的數(shù)據(jù)都通過“MongoDB云上災(zāi)備”異步地將數(shù)據(jù)同步到另外兩個(gè)機(jī)房。然后通過高德的路由層，將用戶請(qǐng)求路由到不同的數(shù)據(jù)中心，讀寫均發(fā)送在同一個(gè)數(shù)據(jù)中心，保證一定的事務(wù)性。這樣保證每個(gè)數(shù)據(jù)中心都有全量的數(shù)據(jù)(保證最終一致性) 。任意機(jī)房出現(xiàn)問題，另兩個(gè)機(jī)房中的一個(gè)可以通過切換后提供讀寫服務(wù)。下圖展示了城市1和城市2機(jī)房的同步情況。

遇到某個(gè)單元不能訪問的問題，Manager通過“MongoDB云上災(zāi)備”產(chǎn)品管理接口，可以獲得各個(gè)機(jī)房的同步偏移量和時(shí)間戳，通過判斷采集和寫入值即可判斷異步復(fù)制是否在某個(gè)時(shí)間點(diǎn)已經(jīng)完成。再配合業(yè)務(wù)方的DNS切流，切走單元流量并保證原有單元的請(qǐng)求在新單元是可以讀寫的，如下圖所示。

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。