?[[273644]]?

本文將主要首先聊一聊數據庫同步和遷移兩個話題，之后將會圍繞這 2 個話題介紹一下阿里云開源的基于 MongoDB 和 Redis 的數據同步&遷移工具 MongoShake 和 RedisShake，最后介紹一些用戶的使用案例。

1. 同步

現在大部分數據庫都支持集群版的數據，也就是說一個邏輯單元中有多個 db 節點，不同節點之間通常通過復制的方式來實現數據的同步。比如 MySQL 的的基于 Binlog 的主從同步、Redis 的基于 Sync/Psync 機制的 AOF 主從同步、MongoDB 基于 oplog 的主從同步等等。這些機制支撐了一個單元下的數據冗余高可用和讀寫分離負載分擔。

但僅僅一個邏輯單元內的數據同步對于很多業務通常不夠用，很多業務需要跨邏輯單元的數據同步的能力。例如：同城多機房、異地多數據中心同步等。容災、多活是最常見的兩種業務場景，擴展開來還可以有讀寫分離，負載分擔等多種場景。

現在越來越多的公司選擇將基礎業務部署到云上，那么這些能力都需要云廠商能夠提供，以提高服務的質量，更好的為用戶的業務服務。另外，最近混合云場景大熱，其原因有多種，既有云廠商的原因，也有用戶業務變化的原因，但這最終要求了從云下到云上，云上到云下，跨云不同云廠商之間的互相同步的能力。

1.1 容災

容災通常用于數據的備份，備份數據對外不提供服務，或者僅提供讀服務。在機房發生故障的時候，備份數據庫代替原數據庫對外提供服務。一般來說，業務的服務治理模塊發現原服務不可用后，選擇代理層進行流量的轉發，或者采用 DNS 進行切流。其機制基本類似，都是將發送到原數據庫的流量轉發到備份數據庫。

容災系統對 RPO(故障恢復時間)和 RTO(恢復數據的時間點)都有要求。比如：故障要求 3 分鐘內恢復，恢復的數據最多容忍丟失 1s，這些都需要數據同步和服務治理發現配合完成。如果 RPO 和 RTO 的要求很高，那么全量備份通常不可取。因為全量備份通常是定期的，比如一天一次，假如故障的時間恰好發生在全量備份之前，這意味著這接近一天的數據丟失了。數據只能恢復到一天之前。所以這就要求了具有一個實時增量的熱備份能力。

因為數據的全量和增量不斷同步，例如：Redis 的 RDB 文件和 AOF 文件，如果 Redis 發生不可服務，這些 RDB + AOF 文件可以恢復成一個數據庫繼續提供服務。再譬如：MongoDB 的全量 Snapshot + Oplog 增量，也可以恢復成一個完整的數據庫。

另外，備份還可以分為邏輯備份和物理備份。邏輯備份通常指的是數據庫的邏輯層面通過全量文件 + Binlog 文件來實現，而物理備份通常指引擎層面來進行備份。

以上提到了關于備份，有很多劃分種類。比如：冷熱備份、冷熱恢復、物理、邏輯備份、全量、增量備份等等，關于這些概念如果不清晰可以自行搜索一下。此外，我們在本小節的開頭提到，備份還可以提供一個讀服務，那對于這種場景來說，備份數據不能單單是一些文件，例如：RDB 文件，AOF 文件等，而需要是一個完整可服務的數據庫，所以這種場景下，通常也需要是一個實時增量的熱備份。

1.2 多活

多活對于數據庫層面來說，指的是跨邏輯單元的多個數據庫同時對外提供服務，這些不同單元的數據庫具有部分相同或者全部相同的數據。這通常用于解決因地域網絡傳輸層面帶來的問題，也就是異地多活。比如：業務層面在北京機房寫入一條數據，要求在上海機房也能讀到這條數據;同樣反過來也可以，在上海機房寫入的數據，在北京也能讀到。

多活的模式看起來很好，能解決很多業務層面的問題，但同時有很多問題和挑戰：

如何解決雙向復制的問題?

兩個數據庫互相同步數據，那難免數據會成環導致風暴。

舉個例子：假如 A 數據庫和 B 數據庫互相同步，我在 A 數據庫插入一條數據：insert x。那么這條數據通過同步鏈路會被同步到 B 數據庫，這時候 B 數據庫也插入了這條數據：insert x。又由于反向同步鏈路的存在，這條數據又會被同步回 A 數據庫: insert x。長此往復，數據就成環了。

該怎么辦呢?答案就是，這種雙向復制如果僅依賴通道層面來解決基本不可行。通常需要配合數據庫內核或者業務層面來解決，比如：數據庫內核增加全局唯一字段，標識數據產生地，而通道在拉取數據時，只拉取數據的產生地 id=當前數據庫 id 的數據，打破成環。亦或者在鏈路層面增加過濾，比如從源庫只拉取 db=a,b 的數據，從目的庫只拉取 db=c 的數據。

這樣數據保證不會成環，而源和目的兩個庫都有全套的db=a, b, c 三個數據庫的數據。然后通過業務層面配合，將 db=a, b 庫的寫數據分發到源庫，db=c 庫的寫數據分發到目的庫來實現。對于開源數據庫模式下，第二種模式也是最常見的模式，在后面介紹 MongoShake 和 RedisShake 我們會詳細介紹這種模式。

如何解決數據雙寫的問題?

也就是說，如何保證在兩個數據庫同時對一條數據進行操作，而結果是正確的。

同樣舉個例子，假設在源數據庫 A 和目的數據庫 B 有一條數據 x=1，我先在 A 庫操作了 set x=2，而后在B庫操作了 set x=3，那么能保證最后2個庫的結果都是 3 嗎?

答案是否定的，因為數據同步是最終一致性，而最終一致性勢必是有時間窗口的。在 B 庫操作 set x=3 的時候，可能 A 庫之前的 set x=2 語句還沒有完成同步，那么先 set x=3，后同步 set x=2，結果目的端就變成了 2，而源端同步了set x=3 結果變成了3，這樣數據就變成了不一致。

當然我這里只是隨便舉個例子，還有很多不一致的情況。那么解決這種問題同樣也需要兩種手段，其一就是內核層面，其二就是業務配合。內核層面解決的比如 CRDT，其基于一個向量時鐘來處理消息的分發，那么向量時鐘也會帶來沖突，對于沖突的處理需要借助一些手段，比如 last write win、客戶端解決等等。而很多數據庫本身對 CRDT 的支持很不夠，所以這種方案有比較大的局限性。其二就是類似我在如何解決雙向復制的問題里面講到的，對業務流量進行分流解決，由業務保證不會在同步通道的兩側同時對一條數據進行操作。

現在數據庫層面的多活，大部分都是一種偽多活，通常都需要業務層面配合分流來解決。下面我在 MongoShake 和 RedisShake 章節，會對這種業務配合的方式進行展開討論。

2. 遷移

從廣義來說，遷移應該算是同步的一種模式。同步側重于增量，而遷移側重于全量。遷移通常說的是數據庫的搬遷，將源數據庫搬遷到目的數據庫，搬遷之后目的數據庫代替源數據庫繼續提供服務，源數據庫可以選擇下線或者繼續提供服務。

遷移有多種場景，比如：同種數據庫下異構模式遷移。例如：Redis 的主從版遷移到集群版;可以是數據庫的升級遷移，比如：MongoDB 從 3.0 升級到 4.0;也可以是上云遷移，比如：云下的數據庫遷移到云上，或者云上的遷移到云下等等。

遷移的同時，源數據庫可寫可不寫，不寫的話稍微簡單一些。遷移往往不需要遷移增量，只需要做全量遷移即可，但這通常需要業務停寫，很多業務難以接受。可寫的話比較符合大部分業務場景，但對遷移的鏈路就需要有個全量+增量遷移的能力。等遷移完畢，用戶可以對遷移后的數據進行校驗，發現沒問題了，等待一個業務時間點進行一次閃斷切流，將流量分發到目的端，數據就完成了遷移，源數據庫就可以下線了。

上述我提到了，遷移可以用于云下到云上，云上到云下這種混合云場景的遷移。但現在對于很多云廠商來說，從云上到云下的遷移可能比云下到云上的遷移困難一些，因為云上到云下的同步需要能夠從云上拉取數據。對于一些數據庫來說，這些拉取的權限很可能沒有開放。例如：Redis 的Sync 遷移，需要源端開放 Sync/Psync 權限，而很多云廠商出于安全角度考慮是不支持的。這就對遷移工具提出了另一個挑戰，而應對這個挑戰的方式要么就是云廠商支持這種模式，要么就是換一種其他遷移方式。對于阿里云來說，已經開放了用戶的復制權限，使得用戶可以通過 Sync/Psync 進行數據的拉取。另外，RedisShake 本身也支持了其他繞過 Sync/Psync 的同步遷移方式，后續我都會介紹。

3. MongoShake & RedisShake同步遷移工具

阿里云開源了 MongoShake 和 RedisShake，可以用于 MongoDB 和 Redis 的同步和遷移，進一步實現用戶對災備和多活的需求。

3.1 MongoShake

MongoShake 的同步是基于 Oplog 實現的，v1.5 版本開始支持全量同步。其內部具體實現細節可以參考我在云棲社區上寫的文章，本小節主要從功能和應用場景來進行介紹。

項目地址：http://t.cn/AiTChwoV

首先介紹一下主要的功能：

• 全量同步：從源端拉取全量數據寫入到目的端。
• 增量同步：拉取源端的增量數據，寫入到目的端。作為同步遷移工具，MongoShake 最主要的功能肯定是數據的同步，全量加增量就是實現數據同步的基礎。上面我們提到的災備和多活功能就是基于這兩個來實現的。
• 過濾：MongoShake 支持對數據按庫、表過濾，這樣就能夠實現我們在前面提到的，雙向同步的場景。
• 并行復制：MongoShake 內部采用了并行復制的策略，使得最高的 QPS 可以達到 40W。
• 壓縮：MongoShake 支持對數據進行壓縮，通常用于遠距離傳輸的場景。
• HA：MongoShake 可以支持集群 HA 切換，用戶可以通過啟動多個 MongoShake 來啟動主備集群。
• 斷點續傳：MongoShake 通過持久化 checkpoint 信息來支持同步鏈路斷開重連后，數據能夠重新接上進行傳輸。
• 靈活多通道支持：MongoShake 除了支持將源數據寫入目的庫以外，還支持多種通道，比如：TCP/RPC/File/Kafka 等，滿足用戶不同的需求。例如：MongoShake 可以將數據寫入 Kafka，用戶可以從 Kafka 中拉取數據，然后對接到流式計算平臺滿足實時計算的需求。用戶甚至可以自定義通道類型，滿足特殊的業務需求。

下面來簡單列舉一下，有了這些功能，我們可以做什么?也就是說應用場景有哪些?

• MongoDB 集群的異步復制，減少業務雙寫的開銷。
• MongoDB 集群的災備、多活、讀寫分離等業務部署。
• 基于 MongoDB Oplog 的日志分析平臺。
• 基于 MongoDB Oplog 的日志訂閱。用戶可以從例如 Kafka 通道中拉取日志，然后對感興趣的日志進行訂閱。
• MongoDB 集群的數據路由。根據業務需求，結合日志訂閱和過濾機制，可以獲取關注的數據，達到數據路由的功能。
• 基于日志的集群監控。
• Cache 的反向同步?？梢酝ㄟ^日志分析的結果，知道哪些 Cache 可以被淘汰，哪些 Cache 可以進行預加載，從而反向推動 Cache 的更新。

以上只是簡單列舉了幾種應用場景，如果你有不同的玩法或者不同的業務需求，也歡迎跟我聯系，MongoShake 產品還在持續迭代更新中，后續還會有很多有用且好玩的特性會進行持續添加。

??

3.2 RedisShake

RedisShake 的同步是基于向源 Redis 發送 Sync/Psync 命令，然后實現全量+增量拉取并回放來實現的。同樣，具體細節介紹請參考我在云棲社區發表的博客，本文主要從功能角度進行介紹。

項目地址：http://t.cn/E6hqgij

RedisShake 目前主要有以下 5 大功能：

• Dump：從源 Redis 將全量 RDB 文件下載下來。
• Decode：解析指定的 RDB 文件。
• Restore：目的庫根據指定的 RDB 進行全量恢復。
• Sync：支持數據同步，源端可以是單節點 Redis、主從Redis、集群Redis，也支持 Codis，目的端同樣也可以是各種模式的 Redis。
• Rump：支持對源端進行 Key 掃描并全量遷移。這個主要是應對一些云廠商沒有開放 Sync/Psync 權限的情況下，進行全量遷移的場景。

??

RedisShake 的 Sync 模式是目前使用最為廣泛的模式，其通過 RDB 全量并發同步。以及增量異步寫入的方式來提高同步的性能，理論上可以達到毫秒級別的同步延遲。此外，用戶還可以根據 redis-full-check 來進行數據同步后的一致性校驗，保證數據的正確性。

RedisShake 的場景以同步為主，如果用戶有特定的需求，也歡迎告知我們，比如類似 MongoShake 的離線計算等場景。目前 RedisShake 處于剛開源階段，功能點迭代比較快，歡迎大家關注。

4. 使用案例

本節主要介紹一下用戶根據我們的 MongoShake 和 RedisShake 的使用案例

4.1 高德地圖

高德地圖 App 是國內首屈一指的地圖及導航應用，阿里云 MongoDB 數據庫服務為該應用提供了部分功能的存儲支撐，存儲億級別數據?，F在高德地圖使用國內雙中心的策略，通過地理位置等信息路由最近中心提升服務質量，業務方(高德地圖)通過用戶路由到三個城市數據中心，如下圖所示，機房數據之間無依賴計算。

??

這三個城市地理上從北到南橫跨了整個中國 ，這對多數據中心如何做好復制、容災提出了挑戰。如果某個地域的機房、網絡出現問題，可以平滑的將流量切換到另一個地方，做到用戶幾乎無感知?

目前我們的策略是，拓撲采用機房兩兩互聯方式，每個機房的數據都將同步到另外兩個機房。然后通過高德的路由層，將用戶請求路由到不同的數據中心，讀寫均發送在同一個數據中心，保證一定的事務性。然后再通過 MongoShake，雙向異步復制兩個數據中心的數據，這樣保證每個數據中心都有全量的數據(保證最終一致性) 。如下圖所示：

??

任意機房出現問題，另兩個機房中的一個可以通過切換后提供讀寫服務。下圖展示了城市 1 和城市 2 機房的同步情況。

??

遇到某個單元不能訪問的問題，通過 MongoShake 對外開放的 Restful 管理接口，可以獲得各個機房的同步偏移量和時間戳，通過判斷采集和寫入值即可判斷異步復制是否在某個時間點已經完成。再配合業務方的 DNS 切流，切走單元流量并保證原有單元的請求在新單元是可以讀寫的，如下圖所示。

??

4.2 某跨境電商

某跨境電商在中國和海外分別部署了 2 套 MongoDB，其中海外主庫上提供讀寫服務，同時用戶希望把海外的數據拉到國內進行離線計算，以及承擔一部分讀流量，以下是該用戶采用 MongoShake 搭建的鏈路方案：

??

4.3 某著名游戲廠商

某著名游戲廠商采用了 MongoShake 搭建了異地容災鏈路。用戶在 2 個機房分別部署了 2 套應用，正常情況下用戶流量通過北向的 DNS/SLB 只訪問主應用，然后再訪問到主 MongoDB，數據通過 MongoShake 在 2 個機房的數據庫之間進行同步，一旦機房 1 不可用，DNS/SLB 將用戶流量切換到備上，然后繼續對外提供讀寫服務。

??

4.4 采用 Shake 的開源多活方案

這里是我們給出的根據 Shake 創建多活的方案，包括 MongoShake 和 RedisShake。

上文我們介紹在開源 MongoDB 下，可以根據控制流量分發來達到多活的需求。比如下面這個圖，用戶需要編寫一個 Proxy進行流量分發(紅色框)部分流量，比如對 a, b 庫的寫操作分發到左邊的 DB，對 c 庫的寫操作分發到右邊的 DB，源庫到目的庫的 Shake 鏈路只同步 a, b 庫( MongoShake 和 RedisShake 均提供按庫過濾功能)，目的庫到源庫的 Shake 鏈路只同步 c 庫。這樣就解決了環形復制的問題。

總結來說，也就是寫流量通過 Proxy 進行固定策略的分發，而讀流量可以隨意分發到任意 DB。

??

4.5 采用 Shake 的級聯同步方案

這個是一個全球的部署的用戶采用 Shake 搭建的全球混合云級聯方案的示例圖。有些數據庫位于云上，有些位于云下，Shake 提供了混合云不同云環境的同步，還可以直接級聯方式的集群同步。

??

5. 總結

總結主要介紹了一下數據庫同步和遷移的場景，然后結合功能和應用場景介紹了下我們開源的兩款 Shake 工具。目前，我們的 Shake 工具還在持續功能迭代中，歡迎關注我們的 Github，有任何問題歡迎在 Github 上進行提問，也歡迎分享你們的使用場景，以幫助我們更好的完善產品。