一、Canal简介
canal 是用于解析 MySQL 增量日志，提供增量数据订阅。
日志增量订阅的业务包括：
1）数据库实时备份
2）索引构建和实时维护(拆分异构索引、倒排索引等)
3）数据库更新后， cache 实时刷新
4）带业务逻辑的增量数据处理
1.1、Canal官方架构图
1.3、Canal原理
Canal的原理基于MySQL主备复制原理：
1）MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，可以通过 show binlog events 进行查看)
2）MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
3）MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据
canal 工作原理：
1）canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议
2）MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal Server)
3）canal 解析 binary log 对象(原始为 byte 流)
1.3、Canal的客户端多语言支持方式
方式1：多语言客户端
Canal支持 Server-Client 模式
Canal提供了多语言的客户端，用于读取Canal解析后的增量日志。
方式2：借助于MQ的多语言客户端
Canal也支持把增量日志的变更投递到MQ，借助于MQ的多语言客户端来实现多语言消费Canal。
二、Canal Server架构设计详解
2.1、MySQL的binlog简介
1）mysql的binlog是多文件存储
2）通过 binlog filename + binlog position 定位一个LogEvent
mysql的binlog数据格式，按照生成的方式，主要分为：statement-based、row-based、mixed。
mysql> show variables like 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW |
+---------------+-------+
1 row in set (0.00 sec)
目前canal支持所有模式的增量订阅(但配合同步时，因为statement只有sql，没有数据，无法获取原始的变更日志，所以一般建议为ROW模式)
2.2、Canal Server的架构图
1、server代表一个canal运行实例，对应于一个JVM
2、instance对应于一个数据队列 （1个server对应n个instance)
对于每个instance，包含的模块：
1）eventParser ：数据源接入，模拟slave协议和master进行交互，协议解析
2）eventSink ：Parser和Store链接器，进行数据过滤，加工，分发的工作
3）eventStore ：数据存储，供client消费
4）metaManager ：增量订阅&消费信息管理器
2.2.1、EventParser设计
Parser执行步骤如下：
1）Connection前先获取上一次解析成功的位置 (如果第一次启动，则获取初始指定的位置或者是当前数据库的binlog位点)
2）Connection建立链接，发送BINLOG_DUMP指令
3）MySQL开始推送Binaly Log给Canal
4）Canal接收到binlog后，通过parser进行协议解析：补充一些特定信息，如补充字段名字，字段类型，主键信息，unsigned类型处理
5）传递给EventSink模块进行数据存储，是一个串行阻塞操作，直到存储成功，再处理下一条
6）存储成功后，定时记录Binaly Log位置
总结：Parser模块从MySQL拉取增量日志时，也是要传递上一次拉取成功的offset作为参数的。
MySQL binlog的发送接收流程：
Step1：通过HandShake协议进行Client和DB的握手认证
Step2：握手成功以后,Client对DB发送show master status命令，此命令中回带回当前最新binlog存储在哪个文件，以及对应哪个偏移量。如果想从当前开始接收binglog,则在后面发送binlog dump命令的时候用这两个值就好。
Step3：发送show global variables like 'binlog_checksum’命令，这是由于binlog event发送回来的时候需要,在最后获取event内容的时候，会增加4个额外字节做校验用。mysql5.6.5以后的版本中binlog_checksum=crc32,而低版本都是binlog_checksum=none。如果不想校验，可以使用set命令设置set binlog_checksum=none
Step4：向MySQL发送Dump命令
Dump命令包图：
如上图所示,在报文中塞入binlogPosition和binlogFileName即可让master从相应的位置发送binlog event。
一旦发送了BinlogDump命令，master就会在数据库有变化的源源不断的推送binlog event到client。
binlog的类型有三种:
1）Statement：每一条会修改数据的sql都会记录在binlog中。
2）Row:不记录sql语句上下文相关信息，仅保存哪条记录被修改。
3）Mixedlevel:以上两种Level的混合。
2.2.2、EventSink设计
1、数据过滤：支持通配符的过滤模式，表名，字段内容等
2、数据路由/分发：解决1:n (1个parser对应多个store的模式)
3、数据归并：解决n:1 (多个parser对应1个store)
4、数据加工：在进入store之前进行额外的处理，比如join
2.2.2.1、数据1:n业务
为了合理的利用数据库资源， 一般常见的业务都是按照schema进行隔离，然后在mysql上层或者dao这一层面上，进行一个数据源路由，屏蔽数据库物理位置对开发的影响，阿里系主要是通过cobar/tddl来解决数据源路由问题。
所以，一般一个数据库实例上，会部署多个schema，每个schema会有由1个或者多个业务方关注
总结：parser和store为1:n，对于nebula而言，可以是一个storage的wal对应多个业务消费，即多套store，每个业务的过滤规则都不同。
2.2.2.2、数据n:1业务
同样，当一个业务的数据规模达到一定的量级后，必然会涉及到水平拆分和垂直拆分的问题，针对这些拆分的数据需要处理时，就需要链接多个store进行处理，消费的位点就会变成多份，而且数据消费的进度无法得到尽可能有序的保证。
所以，在一定业务场景下，需要将拆分后的增量数据进行归并处理，比如按照时间戳/全局id进行排序归并.
总结：如果数据库数据量非常大，经历了拆库拆表后，那么为了提高消费速度，可以由多个parser并行处理，但这样会导致数据乱序，所以后续再重新做归并排序。
2.2.3、EventStore设计
1、目前仅实现了Memory内存模式，后续计划增加本地file存储，mixed混合模式
2、借鉴了Disruptor的RingBuffer的实现思路
要注意的是，如果生成速度大于消费速度时，以上图为例，如果生产者想要写入 Ring Buffer 中序号 3 占据的节点，因为它是 Ring Buffer 当前游标的下一个节点。但是 ProducerBarrier 明白现在不能写入，因为有一个消费者正在占用它。所以，ProducerBarrier 停下来自旋 (spins)，等待，直到那个消费者离开。
定义了3个cursor：
1）Put : Sink模块进行数据存储的最后一次写入位置
2）Get : 数据订阅获取的最后一次提取位置
3）Ack : 数据消费成功的最后一次消费位置
2.2.4、Instance设计
可以通过配置文件或者console这两种方式二选一在设置一个server启动几个instance。
instance代表了一个实际运行的数据队列，包括了EventPaser,EventSink,EventStore等组件。
2.2.5、Server设计
server代表了一个canal的运行实例，为了方便组件化使用，特意抽象了Embeded(嵌入式) / Netty(网络访问)的两种实现：
1）Embeded（嵌入式）：对latency和可用性都有比较高的要求，自己又能hold住分布式的相关技术(比如failover）-- 例如，可以把Canal Server跟数据库部署在相同的服务器上，但当Canal Server的instance实例故障时，需要自己包装failover，如果可以一个instance对应一个套增量日志，那么当instance故障时，可以通过运维命令自动拉起。
2）Netty（RPC框架）：基于netty封装了一层网络协议，由canal server保证其可用性，采用的pull模型，当然latency会稍微打点折扣，不过这个也视情况而定。(阿里系的notify和metaq，典型的push/pull模型，目前也逐步的在向pull模型靠拢，push在数据量大的时候会有一些问题)。
2.2.6、增量订阅设计
具体的协议格式，可参见：https://github.com/alibaba/canal/blob/master/protocol/src/main/java/com/alibaba/otter/canal/protocol/CanalProtocol.proto
get/ack/rollback协议介绍：
1）Message getWithoutAck(int batchSize)，允许指定batchSize，一次可以获取多条，每次返回的对象为Message，包含的内容为：
a. batch id 唯一标识
b. entries 具体的数据对象，对应的数据对象格式：https://github.com/alibaba/canal/blob/master/protocol/src/main/java/com/alibaba/otter/canal/protocol/EntryProtocol.proto
2）void rollback(long batchId)，顾命思议，回滚上次的get请求，重新获取数据。基于get获取的batchId进行提交，避免误操作
3）void ack(long batchId)，顾命思议，确认已经消费成功，通知server删除数据。基于get获取的batchId进行提交，避免误操作
canal的get/ack/rollback协议和常规的jms协议有所不同，允许get/ack异步处理，比如可以连续调用get多次，后续异步按顺序提交ack/rollback，项目中称之为流式api.
流式api设计的好处：
- get/ack异步化，减少因ack带来的网络延迟和操作成本 (99%的状态都是处于正常状态，异常的rollback属于个别情况，没必要为个别的case牺牲整个性能)
- get获取数据后，业务消费存在瓶颈或者需要多进程/多线程消费时，可以不停的轮询get数据，不停的往后发送任务，提高并行化. (作者在实际业务中的一个case：业务数据消费需要跨中美网络，所以一次操作基本在200ms以上，为了减少延迟，所以需要实施并行化)
流式API设计：
- 每次get操作都会在meta中产生一个mark，mark标记会递增，保证运行过程中mark的唯一性
- 每次的get操作，都会在上一次的mark操作记录的cursor继续往后取，如果mark不存在，则在last ack cursor继续往后取
- 进行ack时，需要按照mark的顺序进行数序ack，不能跳跃ack. ack会删除当前的mark标记，并将对应的mark位置更新为last ack cusor
- 一旦出现异常情况，客户端可发起rollback情况，重新置位：删除所有的mark, 清理get请求位置，下次请求会从last ack cursor继续往后取
2.2.7、数据对象格式
数据对象格式：https://github.com/alibaba/canal/blob/master/protocol/src/main/java/com/alibaba/otter/canal/protocol/EntryProtocol.proto
每次调用get, 访问master的增量日志，返回数据格式如下：
Entry
Header
logfileName [binlog文件名]
logfileOffset [binlog position]
executeTime [binlog里记录变更发生的时间戳]
schemaName [数据库实例]
tableName [表名]
eventType [insert/update/delete类型]
entryType [事务头BEGIN/事务尾END/数据ROWDATA]
storeValue [byte数据,可展开，对应的类型为RowChange]
RowChange
isDdl [是否是ddl变更操作，比如create table/drop table]
sql [具体的ddl sql]
rowDatas [具体insert/update/delete的变更数据，可为多条，1个binlog event事件可对应多条变更，比如批处理]
beforeColumns [Column类型的数组]
afterColumns [Column类型的数组]
Column
index [column序号]
sqlType [jdbc type]
name [column name]
isKey [是否为主键]
updated [是否发生过变更]
isNull [值是否为null]
value [具体的内容，注意为文本]
说明：
1）可以提供数据库变更前和变更后的字段内容，针对binlog中没有的name,isKey等信息进行补全
2）可以提供ddl的变更语句
2.2.8、HA机制设计
canal的ha分为两部分，canal server和canal client分别有对应的ha实现
1）canal server: 为了减少对mysql dump的请求，不同server上的instance要求同一时间只能有一个处于running，其他的处于standby状态.
2）canal client: 为了保证有序性，一份instance同一时间只能由一个canal client进行get/ack/rollback操作，否则客户端接收无法保证有序。
1、canal server要启动某个canal instance时都先向zookeeper进行一次尝试启动判断 (实现：创建EPHEMERAL节点，谁创建成功就允许谁启动)
2、创建zookeeper节点成功后，对应的canal server就启动对应的canal instance，没有创建成功的canal instance就会处于standby状态
3、一旦zookeeper发现canal server A创建的节点消失后，立即通知其他的canal server再次进行步骤1的操作，重新选出一个canal server启动instance.
4、canal client每次进行connect时，会首先向zookeeper询问当前是谁启动了canal instance，然后和其建立链接，一旦链接不可用，会重新尝试connect.
Canal Client的方式和canal server方式类似，也是利用zookeeper的抢占EPHEMERAL节点的方式进行控制.