原文出处： 朱小厮

概述

canal是阿里巴巴旗下的一款开源项目，纯Java开拓。基于数据库增量日志理会，提供增量数据订阅&消费，今朝主要支持了MySQL（也支持mariaDB）。

发源：早期，阿里巴巴B2B公司因为存在杭州和美国双机房陈设，存在跨机房同步的业务需求。不外早期的数据库同步业务，主要是基于trigger的方法获取增量改观，不外从2010年开始，阿里系公司开始慢慢的实验基于数据库的日志理会，获取增量改观举办同步，由此衍生出了增量订阅&消费的业务，以后开启了一段新纪元。

基于日志增量订阅&消费支持的业务：

1. 数据库镜像
2. 数据库及时备份
3. 多级索引 (卖家和买家各自分库索引)
4. search build
5. 业务cache刷新
6. 价值变革等重要业务动静

事情道理

mysql主备复制实现：

从上层来看，复制分成三步：

1. master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events，可以通过show binlog events举办查察）；
2. slave将master的binary log events拷贝到它的中继日志(relay log)；
3. slave重做中继日志中的事件，将改变反应它本身的数据。

canal的事情道理

道理相比拟力简朴：

1. canal模仿mysql slave的交互协议，伪装本身为mysql slave，向mysql master发送dump协议
2. mysql master收到dump请求，开始推送binary log给slave(也就是canal)
3. canal理会binary log工具(原始为byte流)

架构设计

小我私家领略，数据增量订阅与消费该当有如下几个点：

1. 增量订阅和消费模块该当包罗binlog日志抓取，binlog日志理会，事件分发过滤（EventSink），存储（EventStore）等主要模块。
2. 假如需要确保HA可以回收Zookeeper生存各个子模块的状态，让整个增量订阅和消费模块实现无状态化，虽然作为consumer(客户端)的状态也可以生存在zk之中。
3. 整体上通过一个Manager System举办会合打点，分派资源。

可以参考下图：

canal架构设计

说明：

server代表一个canal运行实例，对应于一个jvm

instance对应于一个数据行列 （1个server对应1..n个instance)

instance模块：

eventParser (数据源接入，模仿slave协议和master举办交互，协议理会)

eventSink (Parser和Store链接器，举办数据过滤，加工，分发的事情)

eventStore (数据存储)

metaManager (增量订阅&消费信息打点器)

EventParser

整个parser进程大抵可分为几部：

1. Connection获取上一次理会乐成的位置（假如第一次启动，则获取初始拟定的位置可能是当前数据库的binlog位点）
2. Connection成立毗连，产生BINLOG_DUMP呼吁
3. Mysql开始推送Binary Log
4. 吸收到的Binary Log通过Binlog parser举办协议理会，增补一些特定信息
5. 通报给EventSink模块举办数据存储，是一个阻塞操纵，直到存储乐成
6. 存储乐成后，按时记录Binary Log位置

EventSink设计

说明：

数据过滤：支持通配符的过滤模式，表名，字段内容等

数据路由/分发：办理1:n (1个parser对应多个store的模式)

数据合并：办理n:1 (多个parser对应1个store)

数据加工：在进入store之前举办特另外处理惩罚，好比join

1 数据1:n业务 ：

为了公道的操作数据库资源， 一般常见的业务都是凭据schema举办断绝，然后在mysql上层可能dao这一层面上，举办一个数据源路由，屏蔽数据库物理位置对开拓的影响，阿里系主要是通过cobar/tddl来办理数据源路由问题。 所以，一般一个数据库实例上，会陈设多个schema，图纸加密，每个schema会有由1个可能多个业务方存眷。

2 数据n:1业务：