otter是阿里巴巴的开源的一款数据数据同步工具，它基于对数据库增量日志解析，准实时同步到本机房或者异地机房的mysql/oracle/mq等，是一个分布式数据同步系统。otter第一版本可追溯到04~05年，开发时间从2011年7月份一直持续到现在；当时因阿里巴巴的业务特点，买家主要集中在国外，卖家在国内，因此诞生了杭州和美国异地机房，同时为了提升用户体验，整个机房是一个双A架构，两边均可写，由此诞生了otter这样一个产品；2019年otter更新版本为4.2.19-SNAPHOST后未再做大的版本更新。

      otter的主要的使用场景有：

    （1）异构库同步：mysql -> mysql; mysql -> oracle; mysql -> mq

    （2）单机房同步：单机房内部数据同步，数据异构；

    （3）数据迁移：历史数据迁移，全量迁移/增量迁移

    （4）异地机房同步：异步机房同步支持，用于容灾

    （5）双向同步：支持双向同步 A -> B; B -> A;同时避免双向回环

    （6）文件同步

        在讲otter同步原理前需要提一下mysql的日志，otter是基于mysql的增量日志解析来实现数据同步的，这里的日志就是mysql二进制日志——binlog日志，该类型日志详细记录了所有修改的数据的sql，当某一时刻的数据误操作导致问题，或者数据库当即数据丢失，就可以通过binlog日志完成数据的找回。同时binlog日志用于mysql主从数据同步的桥梁，从库通过监控主库的binlog日志，同步主库的所有数据修改。

       otter是通过cannal获取并解析mysql的binlog日志，cannal模拟Mysql slave的交互协议，伪装自己为Mysql的slave，向Mysql master发送dump请求，Mysql master收到dump请求后开始推送binlog日志给slave既cannal，cannal解析binlog日志，解析完成后将数据推送给otter的node节点，然后进行后续的处理。

        otter由cannal、manager、node、zookeeper几部分构成：

     （1）其中cannal负责获取并解析binlog日志。

     （2）manager负责维护系统配置、node节点信息、告警、同步channel任务、数据源等内容，同时同步任务统计数据全部都是在manager展示查阅；  

     （3）node节点主要是从cannal获取解析后的binlog信息，主要经过SETL四个阶段处理，重新组装sql并执行，完成数据的增量同步、存量数据的修改，同时还可以自定义逻辑（实现EventProcessor,详情见：otter 扩展-CSDN博客）完成特殊逻辑的处理。

     （4）zookeeper 主要是完成分布式协调任务，存储节点临时信息，节点状态存储，存储中间数据等。

       otter获取到cannal解析的binlog信息后，由node节点经过SETL四个阶段的处理，最后将数据同步至目标库。otter采用的SEAD的模型将binlog数据信息分成了四个阶段处理，每个阶段完成自身处理的逻辑后将数据推送至下一个阶段，阶段的处理顺序：S -> E -> T -> L，四个阶段的处理顺序不能乱。

      （1）S 阶段的处理由SelectTask任务处理，主要从cannal获取数据并组装成EtleventDate对象，整个SETL阶段都是通过将数据封装成EtleventDate进行传递。

      （2）E阶段处理由ExtractTask任务处理，主要完成数据提取，数据过滤，执行自定义的EventProcess。

      （3）T阶段处理由TransformTask任务处理，主要完成数据转换。

      （4）L阶段处理由LoadTask任务处理，完成数据载入，主要就是组装sql,完成sql执行。

       otter使用的SEAD模型完成数据流的处理，SEAD模型共享thread pool，解决流控机制；提升资源利用率统一编程模型。otter内部为完成数据流的不同状态扭转，提供了三种仲裁器实现，基于memory的仲裁、基于zookeeper的仲裁器、基于Rpc的仲裁器；基于memory的仲裁器，数据传递在内存中，传递数据快，但是存在单点问题；基于Zookeeper仲裁器，将数据存在Zookeeper的持久节点上，可多节点协调处理；基于Rpc仲裁器，在通知下一个阶段处理时会携带需要处理的数据信息；

         上图是基于memory的仲裁器实现的数据扭转时许图，数据在经过SETL四个阶段完成数据处理，每个数据阶段处理完成将数据推送至下一个阻塞队列由下一个阶段的任务处理器完成数据处理再推向下一个阶段。基于memory仲裁实现的过程中数据一直在process中，S阶段处理完后数据存入process的Map结构中，key为processId，E阶段处理完后重新再将数据放入process中，替换掉原来的EtlEventData；中间阻塞队列是存储与processId信息。