Canal是阿里巴巴开源的一款数据库同步组件，它通过分析MySQL数据库的更新日志Binlog将更新的数据推送到不同的消费方来达到数据同步的目的；
首先要了解，MySQL数据库是一种日志优先的数据库，日志优先意思是每次在更新数据时先将修改的数据信息写入日志，然后才会进行数据更新，这样做的目的是保证高可用性，如果数据更新异常，可以通过日志来操作回滚或重试；MySQL日志以二进制的方式存储，因此简称为BinLog（BinaryLog）;
当MySQL数据库存在主从库时，主库会将BinLog发送到从库称为RelayLog，从库会根据RelayLog对从库数据进行同样的修改，从而达到主从数据一致的目的；
MySQL的日志格式有三种：行模式、命令模式、混合模式；
行模式：日志中会记录每一行数据被修改的形式，然后在slave端再对相同的数据进行修改
优点：在行模式下，binlog可以不记录执行的sql语句信息，仅仅记录每一行数据修改之前的值和修改之后的值，binlog会非常清楚的记录下每一行数据修改的细节。不会出现语句模式中主从不一致的问题
缺点：所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，会产生大量的日志内容
Statement Level 语句模式（默认）：每一条会修改数据的sql都会记录到master的bin-log中。slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行
优点：首先就是解决了行模式的下的缺点，不需要记录每一行数据的变化，减少binlog日志量，节约IO，提高性能
缺点：由于只记录语句，所以在语句模式下，已经发现了有不少情况下会造成主从不一致的问题，例如使用系统函数UUID（），用户自定义方法，存储过程，触发器等
Mixed 混合模式：MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志格式，也就是在Statement和Row之间选择一种
Canal的实现原理很简单，CanalServer通过模拟slave从库向主库发送dump请求，主库接收到dump请求后会向其发送BinLog，Canal对接收到的字节流形式的binlog进行解析；
Canal的架构：
server代表一个canal运行实例，对应于一个jvm
instance对应于一个数据队列 （1个server对应1..n个instance)，负责模拟不同的DB-Slave,一个instance对应一个DB,因此server与instance为一对多的关系，当监听多个DB的数据变化就会有多个instance；
eventParser 数据源接入，模拟slave协议和master进行交互，协议解析
eventSink Parser和Store链接器，进行数据过滤，加工，分发的工作
eventStore 数据存储
metaManager 增量订阅&消费信息管理器
在Canal架构中要重点介绍一下Event的存储，目前只实现了内存模式，即Event存放在内存中；
其存储结构为RingBuffer：
Put: Sink模块进行数据存储的最后一次写入位置
Get: 数据订阅获取的最后一次提取位置
Ack: 数据消费成功的最后一次消费位置
Event的存储数量是有限制的，当RingBuffer存放不下新的Event时会通知Master延迟发送binlog；
Canal的高可用性时通过Zookeeper来保证的：
为了减少对mysql dump的请求，不同server上的instance要求同一时间只能有一个处于running，其他的处于standby状态；
Canal原生支持HA机制下启动，只需配置相关的配置，无需额外的工作量；
Canal Server HA机制启动流程（如图所示）
第一步当不同sever上的监听相同DB的instance尝试启动时，需要去Zookeeper上注册节点，如果发现没有活跃节点，则进行启动，否则进入StandBy状态，当正在运行的instance出现故障时，比如ServerA 挂掉了，这时Zookeeper检测到ServerA上的instance已经不可用，通知ServerB上相应的instance进行启动；
通过上面我们已经了解了CanalServer的具体实现原理，CanalSever只是实现了对数据库信息更新的感知，需要有相应的消费者来消费这些消息来达到各自的业务目标，Otter同样是阿里巴巴开源的一款工具，它可以对数据库变更的信息进行统一消费并按照不同的方式推送到各个消费方，而使用者只需在Otter平台上配置相应的规则即可实现；
