全部文档索引：
Otter源代码解析（一）： http://eyuxu.iteye.com/blog/1941894Otter源代码解析（二） ： http://eyuxu.iteye.com/blog/1942518
Otter源代码解析（三）： http://eyuxu.iteye.com/blog/1942519
Otter源代码解析（四）： http://eyuxu.iteye.com/blog/1942521
Otter源代码解析（五）： http://eyuxu.iteye.com/blog/1942522
Otter源代码解析（六）： http://eyuxu.iteye.com/blog/1942549
Otter源代码解析（七）： http://eyuxu.iteye.com/blog/1942578
Otter源代码解析（八）： http://eyuxu.iteye.com/blog/1942780
Otter源代码解析（九）： http://eyuxu.iteye.com/blog/1942786
写在前面：
最近在做跨机房数据传输的技术选型，看了几个第三方的框架，SymmetricDS（http://www.symmetricds.org/） 、tungsten-replicator（
https://code.google.com/p/tungsten -replicator/）、阿里的Otter（https://github.com/alibaba/otter/ ）。比较下来Otter在功能上的优势还是比较大，所以决定将Otter作为最终的选型结果。不过跨机房的数据传输是个很复杂的过程，Otter的实现也是比较复杂的，因此在投入使用前，需要对Otter的实现细节有一个较为清楚的了解，只靠官方文档上的介绍是远远不够的。而了解实现细节的最好的方式就是阅读源代码。
1. 简介
Otter是阿里开源的一个多机房数据复制的产品，内嵌Canal（基于BinLog模式获取数据库变更数据的开源产品），两款产品官方提供了一些文档说明，但是1）官方说明中有一些比较难于理解的地方；2）从使用角度来说，仅仅了解官方说明的内容是不够的，理解最好的方式还是针对源代码进行分析，还原详细设计。本文对Otter的一些比较关键、比较复杂的地方做了设计还原，给阅读代码的人提供一些帮助，或者希望进一步了解Otter的开发人员提供补充材料。
分析的版本：4.2.1
2. 参考资料
Otter的官方地址：https://github.com/alibaba/otter/ （简介、架构介绍、QuickStart等，读者需要首先了解这篇文档，然后才能阅读本文）
Canal的官方地址：http://github.com/alibaba/canal （简介、架构介绍、QuickStart等，读者需要先看下Canal的文档，才能阅读本文）
3. 工程结构解析
Canal的架构这里就不做说明了，相关文档说明、设计思路还是比较清楚的，我只花了一天左右的时间看了看源码，结构很清楚，也比较容易理解。但是Otter就理解起来就比较困难了，并不是设计的不够简洁，而是其本身的逻辑就比较复杂，尤其涉及到S.E.T.L调度的细节上面。
先看下工程结构：
包含三部分：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
下面会针对一些比较关键的内容（全文解析太多了）做下解析说明。
未完待续。