【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】
