Otter源代码解析（一）

全部文档索引：

Otter源代码解析（一）： http://eyuxu.iteye.com/blog/1941894

Otter源代码解析（二） ： 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

 

下面会针对一些比较关键的内容（全文解析太多了）做下解析说明。

 

未完待续。

 

评论

1 楼 RAYFUXK 2016-04-01  

楼主你好，我想请教下，源节点canal的Entry数据是通过Dubbo传到目标节点的么？