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

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

應用場景

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

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

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

NDC的產(chǎn)品形態(tài)有兩大特性：一是平臺化，二是插件化。

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

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

系統(tǒng)架構

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

運維管理的API管理組件圖

遷移和訂閱的執(zhí)行節(jié)點圖

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

高可用實踐

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

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

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

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