NDC是網(wǎng)易近一年新誕生的結構化數(shù)據(jù)傳輸服務，它整合了網(wǎng)易過去在數(shù)據(jù)傳輸領域的各種工具和經(jīng)驗，將單機數(shù)據(jù)庫、分布式數(shù)據(jù)庫、OLAP系統(tǒng)以及下游應用通過數(shù)據(jù)鏈路串在一起。除了保障高效的數(shù)據(jù)傳輸外，NDC的設計遵循了單元化和平臺化的設計哲學，本篇文章將帶大家近距離了解NDC的設計思路和實現(xiàn)原理。

NDC簡介

NDC全名Netease Data Canal，直譯為網(wǎng)易數(shù)據(jù)運河系統(tǒng)，是網(wǎng)易針對結構化數(shù)據(jù)庫的數(shù)據(jù)實時遷移、同步和訂閱的平臺化解決方案。

在NDC之前，我們主要通過自研或開源軟件工具來滿足異構數(shù)據(jù)庫實時遷移和同步的需求，隨著云計算和公司業(yè)務的大力推進，公司內(nèi)部，尤其是運維團隊開始對數(shù)據(jù)遷移工具的可用性、易用性以及其他多樣化功能提出了更多要求和挑戰(zhàn)，NDC平臺化解決方案便應運而生。NDC的構建快速整合了我們之前在結構化數(shù)據(jù)遷移領域的積累，于2016年8月正式立項，同年10月就已上線開始為我們的各大產(chǎn)品線提供在線數(shù)據(jù)遷移和同步服務。

業(yè)界中與NDC類似的產(chǎn)品有阿里云的DTS、阿里開源產(chǎn)品DataX、Canal、Twitter的Databus，在傳統(tǒng)領域有Oracle的GoldenGate、開源產(chǎn)品SymmetricDS。從產(chǎn)品功能、成熟度來看，NDC與阿里云DTS最為相似，都具有簡、快、全三大特性：

• 簡，使用簡單，有平臺化的Web管理工具，配置流程簡潔易懂。
• 快，數(shù)據(jù)同步、遷移和訂閱速度快，執(zhí)行高效，滿足互聯(lián)網(wǎng)產(chǎn)品快速迭代的需求。
• 全，功能齊全，NDC支持多種常用的異構數(shù)據(jù)庫，包括Oracle、MySQL、SQLServer、DB2、PostgreSQL以及網(wǎng)易分布式數(shù)據(jù)庫DDB，除了可以滿足不同數(shù)據(jù)庫之間在線數(shù)據(jù)遷移、實時同步之外，NDC也可以實現(xiàn)從數(shù)據(jù)庫到多種OLAP系統(tǒng)的實時數(shù)據(jù)同步和ETL，目前同步目標支持的OLAP系統(tǒng)包含Kudu和Greeplum。另外，NDC支持對數(shù)據(jù)庫做數(shù)據(jù)訂閱，通過將數(shù)據(jù)庫的增量數(shù)據(jù)丟入消息隊列，使應用端可以自由消費數(shù)據(jù)庫的實時增量數(shù)據(jù)，從而實現(xiàn)由數(shù)據(jù)驅(qū)動業(yè)務，復雜業(yè)務之間調(diào)用解耦。

提煉場景和需求是做好產(chǎn)品的第一步，本文先通過三種典型應用場景介紹NDC的使用價值，之后從產(chǎn)品形態(tài)和系統(tǒng)架構兩方面闡述NDC在產(chǎn)品交互、集群管理、資源調(diào)度以及跨機房部署上的設計理念，最后介紹NDC實現(xiàn)數(shù)據(jù)遷移、同步和訂閱的一些原理和關鍵特性，可以為開發(fā)者在實現(xiàn)類似功能時提供思路和參考。

應用場景

下面通過三個真實案例分別說明NDC在數(shù)據(jù)遷移和數(shù)據(jù)訂閱上的應用場景。

DDB數(shù)據(jù)遷移

分布式數(shù)據(jù)庫DDB自2006年就開始為網(wǎng)易各大互聯(lián)網(wǎng)產(chǎn)品提供透明的分庫分表服務，在我們的知名互聯(lián)網(wǎng)產(chǎn)品背后，幾乎都可以看到DDB的身影，如考拉、云音樂、云閱讀、教育等。

DDB作為分庫分表的結構化數(shù)據(jù)庫，一張表的數(shù)據(jù)一般存儲在多個數(shù)據(jù)節(jié)點中，每張表會選擇一個或多個字段作為分區(qū)鍵，來決定數(shù)據(jù)在數(shù)據(jù)節(jié)點上的分布方式。以用戶表為例，有用戶ID作為主鍵，電話號碼和郵箱作為唯一健，分區(qū)鍵一般會選擇這三個字段中的任意一個或組合。分區(qū)鍵的選擇決定了數(shù)據(jù)分布均勻與否，隨著業(yè)務數(shù)據(jù)量的增長，可能會發(fā)現(xiàn)之前選擇的分區(qū)鍵區(qū)分度不夠高，而需要更改分區(qū)鍵的需求，分區(qū)鍵的修改涉及到數(shù)據(jù)重分布，并且修改過程要與業(yè)務的線上服務同時進行，這就要求DDB提供在線數(shù)據(jù)遷移的解決方案。

與此類似，在業(yè)務發(fā)展過程中可能遇到表擴容或機房遷移的情況，都需要DDB的在線數(shù)據(jù)遷移功能，以表擴容為例，NDC解決DDB在線數(shù)據(jù)遷移方式如圖1所示。

圖1 NDC解決DDB數(shù)據(jù)遷移問題

當DBA發(fā)起一個修改分區(qū)鍵或擴容請求時，管理工具會統(tǒng)一將其解析成一個數(shù)據(jù)遷移命令，并向NDC服務發(fā)起相應的調(diào)度請求，NDC則根據(jù)調(diào)度規(guī)則選擇一組執(zhí)行節(jié)點執(zhí)行具體遷移過程，每個源端數(shù)據(jù)節(jié)點都會有對應一個遷移進程來拉取該節(jié)點上的全量數(shù)據(jù)和增量數(shù)據(jù)，并將這些數(shù)據(jù)通過DDB的分庫分表驅(qū)動重新應用到目標表。當目標端和源端的數(shù)據(jù)延遲在追趕到毫秒級范圍內(nèi)后，通過在DDB管理工具上執(zhí)行切換表操作完成最后的遷移工作。

應用緩存更新

應用緩存更新是NDC數(shù)據(jù)訂閱一類非常典型的應用場景，在沒有使用數(shù)據(jù)訂閱做緩存更新的應用環(huán)境中，緩存數(shù)據(jù)通常由應用服務器自己維護，但是由于緩存操作和數(shù)據(jù)庫操作不具有事務性，簡單的緩存操作可能帶來數(shù)據(jù)不一致的情況，如圖2所示。

圖2 緩存數(shù)據(jù)庫不一致問題

在圖2場景中，線程2在將緩存更新到最新數(shù)據(jù)后，又被線程1異步滯后地更新成老數(shù)據(jù)，由于線程1和線程2沒有任何狀態(tài)共享，數(shù)據(jù)庫中后操作的數(shù)據(jù)可能在緩存中被先操作的數(shù)據(jù)覆蓋掉，導致緩存和數(shù)據(jù)庫數(shù)據(jù)不一致。若這種情況出現(xiàn)，除非緩存主動淘汰，否則應用將始終讀到臟數(shù)據(jù)。

對上述的數(shù)據(jù)不一致問題，業(yè)界也有一種基于CAS的解決方案，但會對緩存增加至少一倍以上的壓力。而通過NDC的數(shù)據(jù)訂閱，可以比較完美地解決上述問題，NDC數(shù)據(jù)訂閱將數(shù)據(jù)庫中的增量數(shù)據(jù)丟入消息隊列，應用讀取消息隊列的內(nèi)容，并將其同步到緩存系統(tǒng)，在這個過程中，NDC執(zhí)行節(jié)點和消息隊列保障高可用，而數(shù)據(jù)庫增量數(shù)據(jù)具有唯一性和時序性，可以避免緩存和數(shù)據(jù)庫的狀態(tài)不一致。

如果說使用數(shù)據(jù)訂閱只是緩存更新的一種優(yōu)選方案的話，那對下面的多機房緩存淘汰，NDC的數(shù)據(jù)訂閱功能就是必選方案了。

圖3中，應用部署有主機房和備機房兩套環(huán)境，兩套環(huán)境各有一套應用服務，緩存和數(shù)據(jù)庫，為了保障主備機房數(shù)據(jù)一致，數(shù)據(jù)寫入只能走主機房，備機房數(shù)據(jù)庫是主機房數(shù)據(jù)庫的只讀從庫，這種架構普遍適用于讀多寫少的應用系統(tǒng)。

圖3 NDC解決多機房緩存淘汰問題

在業(yè)務不適用數(shù)據(jù)訂閱來更新緩存的情況下，從機房在執(zhí)行刪除數(shù)據(jù)時，先刪除主機房數(shù)據(jù)，再刪除從機房緩存，而從機房的數(shù)據(jù)庫同步具有一定的滯后性，在滯后的這段時間，從機房應用服務可能會將從機房數(shù)據(jù)庫的臟數(shù)據(jù)重新載入緩存，導致從機房應用依舊能看到刪除后的數(shù)據(jù)。為此，我們的方案是使用NDC訂閱從機房數(shù)據(jù)庫的刪除操作，保障從機房數(shù)據(jù)庫和緩存在刪除操作上具有一致性。

OLAP系統(tǒng)整合/ETL

業(yè)務數(shù)據(jù)庫與OLAP系統(tǒng)的數(shù)據(jù)整合，是互聯(lián)網(wǎng)產(chǎn)品架構中非常重要的一環(huán)。比較傳統(tǒng)的應用一般采用定時從OLTP庫中將數(shù)據(jù)全量導入OLAP系統(tǒng)，比如每天凌晨1點開始把線上MySQL中所有數(shù)據(jù)通過Sqoop導入到Hive。這種做法有極大限制性：首先，ETL的時間完全不可控，這對于時效性比較敏感的數(shù)據(jù)尤為重要;其次ETL過程中對源庫負載壓力非常大，尤其對數(shù)據(jù)量大的應用，而控制ETL對源端負載影響就意味著ETL時間更加失控。

在NDC這樣的系統(tǒng)出現(xiàn)后，架構師們有了更加明智的選擇：通過NDC實現(xiàn)結構化數(shù)據(jù)的增量ETL。首先使ETL從小時級延遲降低到秒級，其次NDC的增量數(shù)據(jù)拉取對源端影響非常小。對直接支持數(shù)據(jù)更新的OLAP系統(tǒng)而言，可以直接通過NDC實現(xiàn)ETL，如Kudu、HBase。對于不支持數(shù)據(jù)更新的系統(tǒng)，如Hive，可以通過NDC的數(shù)據(jù)訂閱功能將數(shù)據(jù)庫增量數(shù)據(jù)發(fā)布到消息隊列，再定時從消息隊列中獲取增量數(shù)據(jù)，并通過MR合并到存量數(shù)據(jù)，當然這里的定時要比原先定時全量的時間間隔小很多，比如每小時、每15分鐘——通過這種方式實現(xiàn)準實時的ETL。

圖4 通過NDC實現(xiàn)OLAP系統(tǒng)整合與ETL

產(chǎn)品形態(tài)

在產(chǎn)品形態(tài)上，NDC具有平臺化、可插拔和單元化三大特性。

平臺化

往前追溯幾年，各種PaaS和SaaS服務還未如現(xiàn)在這般舉目皆是，運維小伙伴還比較習慣以部署軟件的方式為業(yè)務方提供各種服務，比如在NDC之前，我們有軟件包Hamal來支持DDB的各種數(shù)據(jù)遷移工作，DBA在實施DDB擴容時，需要經(jīng)歷以下步驟：

• 準備一定數(shù)量的物理機或云主機跑遷移任務;
• 在這些節(jié)點上部署Hamal進程，配置源端目標端，并發(fā)度等參數(shù);
• 通過Hamal日志或監(jiān)控程序?qū)崟r查看遷移進度;
• 數(shù)據(jù)遷移追趕上線上的數(shù)據(jù)增長后，完成切表或切庫操作;
• 回收Hamal進程，釋放相關資源。

隨著負責的產(chǎn)品越來越多，規(guī)模越來越大，管理員在不同產(chǎn)品的機器、配置之間疲于奔命，大量重復性工作增加了犯錯可能，更要命的是遇到資源不足，可能還要經(jīng)歷漫長的采購周期。對于DBA一類的運維人員，迫切需要一套幫助他們解決采購、部署、調(diào)度以及任務完成后的資源回收等一系列運維工作的平臺化管理工具，這便是NDC。

NDC提供有跨IDC的平臺化Web管理界面和類似云計算的租戶管理概念，產(chǎn)品管理員在使用NDC時，在產(chǎn)品相關租戶下創(chuàng)建、修改和刪除具體的數(shù)據(jù)遷移、同步和訂閱任務，由NDC調(diào)度中心將任務調(diào)度到相關的執(zhí)行節(jié)點。另外配有專門的平臺管理員對NDC整個平臺做容量規(guī)劃，NDC管理界面如圖5所。

圖5 NDC管理界面

圖中可以看到，NDC除了提供基本的任務管理之外，還為管理員提供了大量運行時的監(jiān)控統(tǒng)計數(shù)據(jù)，幫助管理員更好地把控任務進度和狀態(tài)。

可插拔

NDC除了向產(chǎn)品管理員和開發(fā)者直接提供服務外，同時也是DDB數(shù)據(jù)遷移、猛犸(網(wǎng)易大數(shù)據(jù)系統(tǒng))數(shù)據(jù)同步的依賴組件，如圖6所示。

圖6 NDC平臺可插拔特性

在DBA通過DDBAdmin做表擴縮容，更改分區(qū)字段等操作時，DDBAdmin會把請求解析成多個數(shù)據(jù)遷移任務提交給NDC。類似的，未來NDC可能還會支持其他自身有認證功能的平臺系統(tǒng)，比如公有云，為此，NDC 需要做到其他平臺的輕松插拔。

NDC的平臺插拔特性，本質(zhì)上是要支持不同租戶認證的可插拔，因為依賴于NDC之上的其他平臺大都實有自己的租戶認證功能，要求NDC支持這些不同的認證方式是不現(xiàn)實的，我們的做法是“認證服務”，具體的租戶認證交由上層平臺自己完成。與此同時，我們可以按照上層平臺的租戶名對任務做物理隔離和任務視圖的劃分。租戶可插拔的另外一個要點，是NDC自帶的租戶認證需要在API服務內(nèi)實現(xiàn)，從NDC的調(diào)度中心來看，API服務與其他平臺是同一個架構層的不同接入平臺。

NDC可插拔的另一個含義是“功能可插拔”。立項至今，NDC前前后后支持了六種關系型數(shù)據(jù)庫、三種OLAP系統(tǒng)，每種源端和目的端都是通過實現(xiàn)統(tǒng)一的Extractor和Applier接口來支持，而且我們在JAR包上做了合理拆分，以便一些功能修改可以獨立上線。未來對新的源端目的端的支持也可以通過實現(xiàn)接口和新增JAR包在不重啟任何進程的前提下完成擴展。

單元化

可以通過NDC實現(xiàn)跨機房的數(shù)據(jù)同步解決方案，尤其對體量比較大的應用，如網(wǎng)易考拉、云音樂，普遍需要在同城甚至異地機房之間做服務冗余、擴展和容災。相對應地，這些應用所依賴的底層服務也需要具備多機房冗余和擴展的功能，如圖7所示。

圖7 NDC跨機房的單元化解決方案

在一個機房內(nèi)的系統(tǒng)架構中，應用服務無狀態(tài)，緩存、大數(shù)據(jù)，這些有狀態(tài)系統(tǒng)的數(shù)據(jù)來自于數(shù)據(jù)庫的數(shù)據(jù)同步和訂閱，而數(shù)據(jù)庫的數(shù)據(jù)除了本機房內(nèi)應用產(chǎn)生外，也可以來自NDC從其他機房的數(shù)據(jù)同步。從這套架構中可以看出，通過NDC同步機房間的數(shù)據(jù)庫數(shù)據(jù)，再由NDC將數(shù)據(jù)庫的變更同步到大數(shù)據(jù)、緩存、消息隊列，由此驅(qū)動業(yè)務在機房間無縫擴展和冗余。

在圖7中，每個機房內(nèi)從應用服務到數(shù)據(jù)庫，具有一套完整的數(shù)據(jù)鏈路，機房內(nèi)部的網(wǎng)絡、IT資源，相關的各種調(diào)度都具有高度自治性，機房間的耦合模塊只有通過NDC共享數(shù)據(jù)庫數(shù)據(jù)，業(yè)界目前將這種具備完整服務鏈路，且高度自治的跨機房方案稱之為“單元化”，NDC的單元化要求在每個機房內(nèi)部署獨立的調(diào)度中心和執(zhí)行節(jié)點組，需要注意的是，單元化并不包含NDC的API服務，API服務具有無狀態(tài)、請求離散等特性，沒有必要獨立部署，同時跨單元的API才能提供平臺化的管理服務。

值得一提的是，所謂“單元”是一個邏輯概念，一個單元具有物理隔離和高度自治的特性，我們也可以在一個機房內(nèi)部署多個NDC單元，以區(qū)別和隔離不同業(yè)務線，比如我們可以為DDB和猛犸部署一套獨立單元來支撐他們的平臺依賴，不過一個單元基本不會跨機房部署。

系統(tǒng)架構

一個單元內(nèi)的NDC系統(tǒng)架構如圖8所示。

圖8 NDC架構圖

最上層無狀態(tài)的API服務，是一套直接面向用戶的平臺化Web管理工具，API節(jié)點通過RPC向調(diào)度中心Center發(fā)起請求，除了API節(jié)點外，Center也會接受來自DDB管理工具、猛犸管理工具等其他平臺的RPC調(diào)用請求。

Center是NDC的大腦，所有管理、調(diào)度、監(jiān)控、報警工作都需要通過Center來執(zhí)行，Center目前在一個單元內(nèi)屬于單點服務，通過高可用組件做冷備，由于元數(shù)據(jù)統(tǒng)一存儲在NDC的系統(tǒng)庫中，主備Center之間無需數(shù)據(jù)同步。Center會定期收集單元內(nèi)所有Engine節(jié)點的負載狀況、任務執(zhí)行狀態(tài)等信息，以實現(xiàn)均衡的任務調(diào)度，在任務失敗時自動重試或重新調(diào)度，保障任務執(zhí)行具有高可用特性。

Engine是NDC系統(tǒng)中數(shù)據(jù)遷移、同步和訂閱的任務執(zhí)行者，它接收來自Center的調(diào)度請求，并維護一組實際任務執(zhí)行進程Executo。在任務執(zhí)行過程中，Engine負責收集每個執(zhí)行進程的任務狀態(tài)、進度信息，并實時上報給Center。Center不知道任何Executor的存在，任務執(zhí)行進程全權托管于Engine，并由Engine全程監(jiān)控。

“單元”是NDC物理資源隔離的最大單位，除了基于單元的隔離之外，NDC還提供了租戶級別的物理隔離，管理員可以為租戶分配獨占的任務執(zhí)行節(jié)點。在配置任務屬性時選擇“獨占型”任務，則任務只會調(diào)度到屬于該用戶的資源池中，以確保任務執(zhí)行具有節(jié)點級別的隔離性，而普通共享型任務只具備進程級別的隔離性。

實現(xiàn)簡述

NDC是面向結構化數(shù)據(jù)庫的數(shù)據(jù)遷移、同步和訂閱的解決方案，而數(shù)據(jù)同步可以看做一種“永不結束”的數(shù)據(jù)遷移，下面我們就NDC在數(shù)據(jù)遷移、數(shù)據(jù)訂閱以及一些關鍵特性上的實現(xiàn)方式做個簡要介紹。

NDC的訂閱和遷移都以表為單位，如無特別說明，下文中的遷移對象均指要遷移的表。

數(shù)據(jù)遷移

與通常的“遷移”概念不同，NDC的“數(shù)據(jù)遷移”并不是將源端的數(shù)據(jù)挪到目標端，而是在保障對源端數(shù)據(jù)影響盡可能小的前提下，將源端的數(shù)據(jù)“復制”或“同步”到目標端。比如線上數(shù)據(jù)庫到數(shù)據(jù)倉庫的ETL，需要在不影響線上服務質(zhì)量的情況下將數(shù)據(jù)實時同步到數(shù)據(jù)倉庫。又如DDB的在線擴容，也需要在擴容的過程中不影響原有的數(shù)據(jù)節(jié)點。

當用戶通過Web工具啟動一個數(shù)據(jù)遷移任務后，NDC調(diào)度服務會根據(jù)任務類型、調(diào)度算法和節(jié)點負載，在相關的Engine資源池中選擇一個或多個節(jié)點下發(fā)任務，一個遷移任務對應一個源端數(shù)據(jù)庫實例。

數(shù)據(jù)遷移引擎中任務執(zhí)行流程如圖9所示。

圖9 NDC數(shù)據(jù)遷移執(zhí)行流程

從圖中可以看出，全部的數(shù)據(jù)遷移流程包含以下四個步驟：

• 預檢查：檢查資源、網(wǎng)絡可用性、Schema兼容性、用戶權限等;
• 全量遷移：源庫、表中存量數(shù)據(jù)的遷移過程;
• 增量遷移：遷移過程中，源庫、表增量數(shù)據(jù)的遷移過程;
• 數(shù)據(jù)校驗：對源端和目標端同步的數(shù)據(jù)做抽樣校驗。

預檢查階段，NDC會檢查源端和目標端的網(wǎng)絡連通性、空余資源可用性、遷移使用的源端目標端用戶在相關庫表上的權限、白名單、要遷移的Schema是否兼容等。NDC不要求遷移對象在源端目標端的Schema嚴格一致，但要求目標端對源端兼容，比如源端字段類型int到目標端可以為bigint，反之則預檢查報錯，源端目標端在索引結構上允許有差異。

預檢查完成后，NDC任務執(zhí)行進程會立即啟動增量數(shù)據(jù)拉取模塊，在開始拉增量數(shù)據(jù)之后，啟動全量遷移流程。顧名思義，全量遷移是將遷移對象的存量數(shù)據(jù)同步到目標端。NDC的全量數(shù)據(jù)遷移采用“快照讀”，而判斷遷移對象中哪些數(shù)據(jù)是存量數(shù)據(jù)，哪些是增量數(shù)據(jù)的依據(jù)，是在開始全量遷移的時候獲取遷移表的最小主鍵和最大主鍵，在獲取到的最小主鍵和最大主鍵之間的所有數(shù)據(jù)，被認為是存量數(shù)據(jù)，以外則作為增量數(shù)據(jù)處理。之所以沒有像MySQLDump一類的遷移工具使用大事務來劃分存量數(shù)據(jù)，是為了避免大事務令源端回滾段不斷累加的影響(這是針對MySQL而言，對不同類型的源端數(shù)據(jù)庫，大事務都會造成一定的不良影響)，而使用快照讀，會使全量遷移過程中引入一部分增量數(shù)據(jù)，但這部分增量的“臟數(shù)據(jù)”最終會被增量遷移修正，不影響數(shù)據(jù)的最終一致性。

全量遷移以表為單位進行，不同表之間可并發(fā)遷移，增量遷移則以源端實例為單位(想想MySQL的binlog)，所以在一個遷移任務中，所有遷移對象都完成全量遷移后，才會進入增量遷移階段。

增量遷移至少包含兩個線程，第一個是增量數(shù)據(jù)拉取線程，在全量遷移開始之前啟動，負責將源端所有(相關)增量數(shù)據(jù)緩存在本地磁盤;另一個是增量回放線程，在增強遷移過程開始時啟動，它的作用是不斷讀取本地緩存的增量數(shù)據(jù)，并按照時間順序回放到目標端。

由于全量遷移是在增量拉取開始之后才進行的，NDC可以保障全量遷移過程中引入的增量數(shù)據(jù)最終會在目標端回放出來。

全量遷移和增量遷移過程中會有一部分增量數(shù)據(jù)被重復導入，NDC會保障增量數(shù)據(jù)導入具有冪等性。

隨著增量遷移的進行，目標端增量數(shù)據(jù)和源端增量數(shù)據(jù)的時間延遲會逐漸縮短，最終這個延遲控制在1s內(nèi)之后，我們將這個遷移任務定義為同步狀態(tài)。對同步狀態(tài)下的遷移任務，管理員可以選擇實施數(shù)據(jù)校驗，一般建議采用源端5‰到100‰的隨機數(shù)據(jù)校驗源端和目標端的數(shù)據(jù)一致性。

NDC數(shù)據(jù)遷移中的全量遷移、增量遷移以及數(shù)據(jù)校驗都是可選流程，不過NDC要求管理員至少勾選全量遷移和增量遷移中的一種，數(shù)據(jù)校驗是遷移任務進入同步狀態(tài)后的可選操作，不是在提交任務時選擇，可反復執(zhí)行。

在實踐中，當數(shù)據(jù)遷移任務進入同步狀態(tài)后，一般會先執(zhí)行一次數(shù)據(jù)校驗，再執(zhí)行相關的切庫切表操作。而對數(shù)據(jù)同步場景，一般會定期執(zhí)行全量數(shù)據(jù)校驗。

數(shù)據(jù)訂閱

數(shù)據(jù)訂閱是將數(shù)據(jù)庫的數(shù)據(jù)變更實時拉取出來，并交付給下游應用執(zhí)行相應業(yè)務邏輯的過程。與數(shù)據(jù)遷移相比，數(shù)據(jù)訂閱邏輯較為簡單——相當于數(shù)據(jù)遷移中的增量過程，而在應用場景方面，數(shù)據(jù)訂閱可以應對更加多樣化的業(yè)務需求，例如：

• 通過數(shù)據(jù)訂閱維護全文索引一類的第三方索引庫
• 基于數(shù)據(jù)訂閱維護緩存
• 通過數(shù)據(jù)訂閱實現(xiàn)復雜業(yè)務異步解耦
• 實現(xiàn)更加復雜的ETL

數(shù)據(jù)訂閱的執(zhí)行邏輯如圖10所示。

圖10 數(shù)據(jù)訂閱執(zhí)行流程

數(shù)據(jù)訂閱任務由NDC的調(diào)度服務選擇合適的訂閱引擎節(jié)點執(zhí)行，與數(shù)據(jù)遷移增量過程不同的是，數(shù)據(jù)訂閱引擎不會將增量變更數(shù)據(jù)緩存在本地，而是直接丟入消息隊列中(使用了我們的消息隊列服務)，SDK通過消費消息隊列的數(shù)據(jù)實現(xiàn)增量數(shù)據(jù)回放。

之所以用消息隊列代替本地磁盤，是因為SDK的數(shù)據(jù)回放過程完全由應用方把持，速度不可控，若業(yè)務邏輯處理過慢，或下游節(jié)點意外宕機，可能導致增量數(shù)據(jù)大量堆積，這里消息隊列可以當做一個容量足夠大的消息緩存，使SDK端的異步消息回放更加優(yōu)雅。

數(shù)據(jù)訂閱中Engine必須嚴格按照增量數(shù)據(jù)的時間順序串行發(fā)布消息，無法做到類似數(shù)據(jù)遷移增量過程中的并發(fā)復制，這是因為訂閱任務Engine無法感知應用端SDK消費數(shù)據(jù)，并發(fā)發(fā)布消息最終必然導致SDK消費數(shù)據(jù)亂序執(zhí)行。

在實踐中，要特別注意消息隊列對發(fā)布消息的速率瓶頸以及訂閱任務Engine到消息隊列的網(wǎng)絡開銷。

關鍵特性

對NDC的實現(xiàn)部分，再分享三點關鍵特性給大家：

• 并發(fā)遷移
• 斷點續(xù)傳
• 多源適配

對數(shù)據(jù)遷移和同步，速度是生命線：如果遷移速度不夠快，任務永遠無法進入同步狀態(tài)，遷移和同步也無從談起。NDC的全量和增量過程都支持并發(fā)遷移，保障遷移任務能夠盡快地進入同步狀態(tài)。

全量遷移并發(fā)較為簡單，首先可以在不同的表上做并發(fā)遷移，其次數(shù)據(jù)導入目標端的過程也可以并發(fā)執(zhí)行，select數(shù)據(jù)和insert數(shù)據(jù)線程解耦在實踐中能夠極大縮短遷移時間，另外NDC的全量遷移可以配置一次導入操作的數(shù)據(jù)批量數(shù)，減少遷移進程和源端目標端的交互次數(shù)。

增量并發(fā)回放是NDC最重要的核心實現(xiàn)之一，NDC增量回放線程會根據(jù)增量數(shù)據(jù)之間的沖突關系構建一張或多張有向無環(huán)圖，圖中所有入度為0的數(shù)據(jù)節(jié)點都允許并發(fā)回放，增量數(shù)據(jù)導入目標端后會從圖中刪除，從而解鎖其他沖突數(shù)據(jù)。這種算法理論上可最大限度發(fā)揮并發(fā)回放的優(yōu)勢，在實際的性能測試中，NDC的增量并發(fā)回放效率遠高于MySQL 5.7基于Group Commit的并行復制。

斷點續(xù)傳是NDC任務漂移和高可用實現(xiàn)的基礎，是指遷移或訂閱任務異常退出，或進程、節(jié)點crash之后，可以從最近的位置點重新啟動任務。斷點續(xù)傳的實現(xiàn)有兩點前提：一是要求系統(tǒng)定期將任務的位置點信息持久化，在需要時可以從持久化過的位置點恢復任務，NDC的做法是Engine定期將位置點信息上報給Center，由后者將其持久化在系統(tǒng)庫;二是要求遷移和訂閱任務中所有數(shù)據(jù)導入操作(全量和增量)具有冪等性，對此我們可以采用具有replace語義的SQL實現(xiàn)導入操作，對不支持replace語法的目標端，可以使用delete+insert的組合SQL實現(xiàn)類似語義。在實踐中，保障冪等操作絕對是一項省時省力省心的做法。

多源適配的問題主要在于對不同的源端數(shù)據(jù)庫，采用怎樣的方式拉取增量數(shù)據(jù)最為實用和高效，目前主要有以下三種做法：

• 基于日志：MySQL binlog、Oracle redo log;
• 基于CDC：Oracle、DB2、SQLServer;
• 基于觸發(fā)器：適用所有支持觸發(fā)器的數(shù)據(jù)庫。

三種做法各有優(yōu)劣，觸發(fā)器用法較為簡單，對用戶權限要求比較清晰，但性能較差，尤其是源端線上壓力比較大時，可能產(chǎn)生大量的鎖超時，因此不作為最優(yōu)選擇;CDC全名Change Data Capture，是一些數(shù)據(jù)庫特有的功能，可以將數(shù)據(jù)庫產(chǎn)生的增量數(shù)據(jù)同步到一些視圖或表中，遷移或訂閱進程通過這些表和視圖來獲取增量數(shù)據(jù)，可以看出CDC在使用上與觸發(fā)器非常類似，區(qū)別在于CDC是一些數(shù)據(jù)庫獨特功能，可以在性能上做優(yōu)化。以Oracle為例，可以通過解析redo log產(chǎn)生增量數(shù)據(jù)，比通過觸發(fā)器產(chǎn)生增量數(shù)據(jù)的做法對源端的影響要小很多，CDC的劣勢在于不同數(shù)據(jù)庫沒有統(tǒng)一規(guī)范，方言化嚴重，對權限要求更加苛刻。

一般情況下，我們將第一種基于日志的增量數(shù)據(jù)拉取方案列為最優(yōu)。以MySQL為例，MySQL自帶的binlog功能可以直接將日志同步到遠端，對用戶權限、源端數(shù)據(jù)庫性能影響也都在可控范圍內(nèi)。

總結

工欲善其事，必先利其器，NDC顧名思義，就是希望為公司打造一個可以容納各種結構化數(shù)據(jù)庫實時數(shù)據(jù)的“數(shù)據(jù)運河”，并通過運河將數(shù)據(jù)運輸?shù)讲煌康亩耍瑧弥恍枰诠芾眄撁嬷泻唵蔚嘏渲脦讉€參數(shù)，便可將數(shù)據(jù)庫的內(nèi)容輕松整合到其他數(shù)據(jù)或應用系統(tǒng)中。

NDC的快速構建，很大程度上要歸功于我們團隊在分布式中間件、數(shù)據(jù)遷移工具等領域的成果和積累，如果開發(fā)者要設計和實現(xiàn)類似系統(tǒng)，建議多利用開源資源，比如調(diào)度模塊可以考慮集成或使用Apache Azkaban的實現(xiàn)，任務執(zhí)行模塊也有很多開源工具和代碼可以參考。另外，在設計數(shù)據(jù)遷移和訂閱平臺時要重點考慮以下幾個問題：

與其他平臺集成，NDC具有平臺可插拔特性，可以非常方便地與網(wǎng)易其他平臺服務集成。

任務執(zhí)行要快，對源端影響盡可能小。NDC具有非常高效的數(shù)據(jù)全量遷移和增量數(shù)據(jù)回放模塊，在實現(xiàn)增量數(shù)據(jù)拉取模塊時，盡可能選擇了同步日志的方式，對源端影響很小。

要考慮到斷點續(xù)傳問題。在任務執(zhí)行過程中，可能發(fā)生網(wǎng)絡抖動、分區(qū)、節(jié)點故障等各類異常，這首先要求我們的任務具備從某個時間點或位置點重新開始執(zhí)行的能力，其次要求調(diào)度中心可以快速發(fā)現(xiàn)異常，并使用合理的算法實現(xiàn)任務漂移。

要考慮到灰度發(fā)布。由于NDC的平臺化設計，隨著系統(tǒng)功能愈發(fā)繁多，一次平臺全面升級的代價越來越高，為此我們需要通過灰度升級保障功能在全面上線之前得到充分驗證，另外通過功能“可插拔”的特性，保障一次上線對線上任務的影響盡可能小。

迄今為止，NDC上線半年多，承接應用40+，遷移、同步和訂閱實踐案例10000+，可以預見，在網(wǎng)易未來的云計算、大數(shù)據(jù)布局，以及其他各類數(shù)據(jù)驅(qū)動的應用場景中，NDC都將發(fā)揮舉足輕重的作用。