Otter源代码解析（一）
?包含三部分：Share | Node | Manager。 其中Share是Node和Manager共享的子系统，并不是独立部署的节点。Node和Manager是独立部署的。
?
Node：一个独立部署的节点，比如两个机房需要做通讯，则每个机房至少要部署一个Node节点（不考虑HA的话），数据同步的过程实际上都发生在Node之间
?
Manager：管理的节点，逻辑上只有一个（一个Manager管理多个Node节点），如果不考虑HA的话。负责管理同步的数据定义，包括数据源、Channel、PipeLine、数据映射等，各个Node节点从Manager处获取并执行这些信息。另外还有监控等信息。
?
Share各个子系统的说明：
? ? . Common: 公共内容定义
? ? .Arbitrate: 用于Manager与Node之间、Node与Node之间的调度、S.E.T.L几个过程的调度等；
? ? .Communication 数据传输的底层，上层的Pipe、一些调度等都是依赖于Communication的
? ? ? ? ? ? ?简单点说它负责点对点的Event发送和接收
? ? ?.etl:实际上并不负责ETL的具体实现，只是一些接口&数据结构的定义而已，具体的实现在Node里面。
?
Node各个子系统的说明：
? ? ? . Common：公共内容定义
? ? ? . Canal: Canal的封装，Otter采用的是Embed的方式引入Canal（Canal有Embed和独立运行两种模式）
? ? ? . Deployer：内置Jetty的启动
? ? ? . etl: S.E.T.L 调度、处理的实现，是Otter最复杂、也是最核心的部分，花了我好几天的时间理解。
?
4. 阅读代码过程中的一些可能的障碍
? ? ?. 池化：代码里面很多提到“池化”这个概念，不知道是阿里内部的叫法还是通用的叫法，反正我之前没有听过，实际上就是使用对象池的方式管理对象。 原因是里面很对对象都是包含线程池的，对于线程池的销毁和加载是比较低效的，所以代码里面对带有线程池的地方基本都做了池化处理（但是线程池的大小每次操作的时候都需要根据实际情况调整）；
? ? ?. retl_mark: 我的理解是具体的业务在执行事务的时候在事务头&尾插入一个标记，在同步BinLog的时候就会发现它，对于不需要同步的数据打上特殊标记（比如_SYNC), ?这样在S.E.T.L的过程中就可以过滤掉这些数据（可以参见：com.alibaba.otter.node.etl.select.selector.MessageParser这个类的实现）
? ? ? . 数据库反查：正常同步的内容是基于BinLog的，即BinLog有什么数据就同步什么数据，但是如果同步的数据延迟时间比较长的话，可能在同步的数据已经发生了变化（即BinLog里面的数据已经是旧的数据了），为了避免这个问题，在Extract阶段根据条件进行数据库查询，可以参见：com.alibaba.otter.node.etl.extract.extractor.DatabaseExtractor
?
下面会针对一些比较关键的内容（全文解析太多了）做下解析说明。
?
未完待续。
?
