【51CTO.com原創稿件】NDC全稱Netease data canal，即網易數據運河，是一個平臺化的結構化數據傳輸系統，目的是解決結構化數據的實時遷移、同步、訂閱、OLTP到OLAP的實時數據整合等問題。我們希望能夠借此將數據庫中的數據與其他系統打通，從而構建一個能夠整合所有數據庫的“數據運河”，任何系統都能夠從“運河”中獲取數據。

此次由51CTO主辦的2017WOTA全球架構與運維技術峰會上，網易資深工程師馬進老師分享了主題為《網易數據傳輸服務NDC高可用實踐》的演講。

應用場景

從應用方視角看來，可以將NDC的應用場景分為三類：***類是數據遷移，像DDB到Oracle這樣的異構數字遷移，同時可以解決DDB內部在線擴容問題和遷移問題。第二類數據同步，場景較為復雜一些，如跨域甚至跨國的數據實時同步，一般不強調異構，需要解決的是高延遲，復雜拓撲管理的問題。第三類數據訂閱，通過數據來驅動業務，實現業務間異步解耦。

***，通過這些應用場景可以總結出NDC的兩個核心需求：***，獲取數據庫實時變更的能力。第二，數據快速發布的能力。如MySQL到Oralce的數據遷移，需要增量遷移的速度要比MySQL線上增量更新快，否則相遷移或者同步永遠無法完成，這就考驗NDC數據發布的速度。另外一點，是需要NDC提供完善的高可用方案，允許數據重復，但是不能丟，還要提供一個不停服務的能力。

產品形態

NDC的產品形態有兩大特性：一是平臺化，二是插件化。

平臺化，網易自有一個平臺化的Web管理工具，主要負責其資源管理和調度，以及平臺化報警監控。

插件化，是對不同數據源、物理端通過applier插件進行的敏捷開發，以及賬號系統插件化。NDC作為底層的中間件能夠支撐不同平臺，像網易的公有云，就會依賴到NDC。不同帳號系統之間也是不太一樣的，當想要接入不同的帳號系統，卻不做插件化的話，成本也就會比較高，而且會使系統變得比較復雜。所以NDC想到的方案就是系統本身不具備用戶管理功能，更多是把用戶作為一個類型存儲到任務的屬性里。然后在管理層向外部做數據用戶認證。

系統架構

網易是有系統庫的，但是不用來做用戶管理，反而會在API服務里定義不同的用戶監護插件，當不同平臺的用戶介入到API服務后，網易會調用不同的插件去認證所對應的用戶。認證后會將用戶打碼，通過中心的Center記錄到人物屬性中去，在這里就能實現用戶接入性的插件化。Center組件也就是調度監控中心，目前使用主備模式實現高可用。

運維管理的API管理組件圖

遷移和訂閱的執行節點圖

通過給執行節點劃分節點組，達到物理隔離的效果，類似于公有云可用域的概念。數據源NDC目前支持DDB、Oracle，SQL Server等，目的端除了關系型數據庫以外還支持Hbase，Greenplum等支持數據更新的數據倉庫。數據訂閱就是把增量數據發布到Kafka，執行節點的每一個遷移都是獨立的進程，這樣就可以避免不同進程間的相互影響。

高可用實踐

Center高可用，也就是網易調度中心的高可用。分享前，馬進老師先同大家講述了腦列問題。嚴格地說，通過zookeeper或keepalived方案實現的高可用，并不能避免死鎖情況的發生，為此NDC通過又在數據庫加鎖的方式完全規避了腦裂的可能：具體做法是在每次做運維操作前先嘗試把leader鎖住，再把數據取出，對比和當前的ID是否一致，如果一致就可以做相應的運維操作。切主的時候，也是現場時把leader鎖住再更新。通過鎖的方式可以保證運維操作和切主的過程是互斥的，從而可以避免腦列問題的產生。但是在這之前也有兩個基本前提：***個就是所有的Center是保持在系統庫，其次就是系統庫是高可用的。

任務高可用需要注意的是，需要主動檢測源端是否活躍，如果發現源端斷了，向Center上報，如果Center監測源端可用的話就可以將任務進行漂移，把原先Engine上的任務漂移到另一個Engine上；如果檢測源端是不可用的，就會嘗試將源端漂移到從庫上。

高可用的設計原則：首先，監控要先于高可用。其次，高可用的分層不要過度設計。像考慮Center高可用的時候相當于做了層次劃分，Center高可用首先依賴于系統庫高可用。第三，高可用插件化，保持系統簡潔。第四，多重驗證，避免誤切。***，源端漂移問題。如果說源端發生了漂移，那么怎么保證數據不丟？馬進老師分享了一個非常簡單的方案，就是依賴MySQL的GTID功能。還有基于觸發器，通過觸發器可以把增量數據直接導入表里，這樣數據就是不會丟的。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】