Canal 架构解析水文

提示：本篇为canalServer模块架构设计解析，一篇浮于表面的水文，水的不能再水的那种。

一、整体架构

1.1 canalServer内部结构图如下：

• server代表一个canalServer运行实例
• instance（server：instance=1：n)，单机模式下对应解压安装包cofig/目录下的example，集群模式下对应admin控制台instance管理栏的一条配置。

从上图内部结构图我们可以看出一个canalServer实例可以收集多个Mysql实例数据 ，下载安装包解压，我们打开其配置文件conf/canal.properties可以看到，上图中的instance单机模式下对应配置文件中的这项:canal.destinations，配置几个就会有几个instance。

#################################################
#########               destinations            #############
#################################################
canal.destinations = example

instance也可以理解为对应一个Mysql实例的一个库，这个要看自己怎么配置使用了,我们可以在instance.properties配置文件里灵活配置，如果将conf/canal.properties配置文件中canal.destinations = example1,example2；并且对应的这两个配置文件中数据库的address配置不同，那么运行时候的架构就是我们上面图中架构，如果address相同，然后通过下面的filter过滤不同的库，那么就是两个instance对应一个Mysql实例了。

# position info
canal.instance.master.address=127.0.0.1:3306
# table regex
canal.instance.filter.regex=.*\\..*

注：如果一个canalServer配置了两个instance，并且部署了一个canalServer实例，那么两个instance， 都是在工作。

如果部署了两个canalServer实例，那么两个实例都是可能各自运行一个instance，也可能两个instance在一个canalServer实例上运行，是基于Zookeeper抢占的，并且这种抢占是instance级别的不是canalServer级别的，先说下搭建使用的版本：canal.admin-1.1.5、canal.deployer-1.1.6

 当我们关掉一个canalServer实例后，另一个实例就会启动这个instance，或者通过canalServer的instance列表里操作-停止：

 但是通过canalServer的instance列表里操作-停止，这个canalServer依旧会发起instance级别的抢占。

所以很多博客说：“多个canal-server只会存在一个是生效的 ”是存疑的，不知道是表述的server级别的还是interface级别的，还是说原来老的版本是server级别的，所以在写博客讲技术时候不带版本号的博文都是在耍流氓。

 1.2 内部处理流程图：

 

• eventParser (数据源接入，模拟slave协议和master进行交互，协议解析)
• eventSink (Parser和Store链接器，进行数据过滤，加工，分发的工作)
• eventStore (数据存储)
• metaManager (增量订阅&消费信息管理器)

二、各模块架构

2.1 eventParser（图片来源网络）

整个parser过程大致可分为几步：

• Connection获取上一次解析成功的位置（如果第一次启动，则获取初始制定的位置或者是当前数据库的binlog位点）
• Connection建立连接，发生BINLOG_DUMP命令
• Mysql开始推送BinaryLog
• 接收到的Binary Log通过Binlog parser进行协议解析，补充一些特定信息
• 传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功
• 存储成功后，定时记录Binary Log位置

2.2 Sink（图片来源网络）

说明：

• 数据过滤：支持通配符的过滤模式，表名，字段内容等
• 数据路由/分发：解决1:n (1个parser对应多个store的模式)
• 数据归并：解决n:1 (多个parser对应1个store)
• 数据加工：在进入store之前进行额外的处理

 2.3 Store（图片来源网络）

目前实现了Memory内存、本地file存储以及持久化到zookeeper以保障数据集群共享。
Memory内存的RingBuffer设计：

每个instance都会将读取到的binary log 解析并写入内存中。供客户端消费，都是单独维护自己的环形队列。

定义了3个cursor

• Put : Sink模块进行数据存储的最后一次写入位置
• Get : 数据订阅获取的最后一次提取位置
• Ack : 数据消费成功的最后一次消费位置

总结

本篇文章讲解了canalServer的架构组成并且还是单机部署的，集群模式无非就是加入了Zookeeper和admin控制台统一管理配置文件和instance文件的管理，搞集群模式之前先单机入门，集群部署需要借助zookeeper来保证只有一个instance工作，其余的冷备，当工作的挂掉了，冷备的节点补充上来，先放张Zookeeper保存数据的节点图以后有时间接着水吧：