基于Canal和Kafka实现MySQL的Binlog近实时同步

近段时间，业务系统架构基本完备，数据层面的建设比较薄弱，因为笔者目前工作重心在于搭建一个小型的数据平台。优先级比较高的一个任务就是需要近实时同步业务系统的数据（包括保存、更新或者软删除）到一个另一个数据源，持久化之前需要清洗数据并且构建一个相对合理的便于后续业务数据统计、标签系统构建等扩展功能的数据模型。基于当前团队的资源和能力，优先调研了

Alibaba

开源中间件

Canal

的使用。

Canal[kə'næl]

，译意为水道/管道/沟渠，主要用途是基于

MySQL

数据库增量日志解析，提供增量数据订阅和消费。

Canal

按照音标的正确读音和"磕尿"相近，而不是很多人认为的

Can Nal

，「笔者曾因此事被开发小姐姐嘲笑」。早期阿里巴巴因为杭州和美国双机房部署，存在跨机房同步的业务需求，实现方式主要是基于业务

trigger

获取增量变更。从 2010 年开始，业务逐步尝试数据库日志解析获取增量变更进行同步，由此衍生出了大量的数据库增量订阅和消费业务。

基于日志增量订阅和消费的业务包括：

• 数据库镜像。

• 数据库实时备份。

• 索引构建和实时维护（拆分异构索引、倒排索引等）。

• 业务Cache刷新。

• 带业务逻辑的增量数据处理。

• MySQL的Master实例将数据变更写入二进制日志（binary log，其中记录叫做二进制日志事件binary log events，可以通过show binlog events进行查看）

• MySQL的Slave实例将master的binary log events拷贝到它的中继日志（relay log）

• MySQL的Slave实例重放relay log中的事件，将数据变更反映它到自身的数据

Canal

的工作原理如下：

• Canal模拟MySQL Slave的交互协议，伪装自己为MySQL Slave，向MySQL Master发送dump协议
• MySQL Master收到dump请求，开始推送binary log给Slave（即Canal）
• Canal解析binary log对象（原始为byte流），并且可以通过连接器发送到对应的消息队列等中间件中

关于Canal的版本和部件

截止笔者开始编写本文的时候（

2020-03-05

），

Canal

的最新发布版本是

v1.1.5-alpha-1

（

2019-10-09

发布的），最新的正式版是

v1.1.4

（

2019-09-02

发布的）。其中，

v1.1.4

主要添加了鉴权、监控的功能，并且做了一些列的性能优化，此版本集成的连接器是

Tcp

、

Kafka

和

RockerMQ

。而

v1.1.5-alpha-1

版本已经新增了

RabbitMQ

连接器，但是此版本的

RabbitMQ

连接器暂时不能定义连接

RabbitMQ

的端口号，不过此问题已经在

master

分支中修复（具体可以参看源码中的

CanalRabbitMQProducer

类的提交记录）。换言之，

v1.1.4

版本中目前能使用的内置连接器只有

Tcp

、

Kafka

和

RockerMQ

三种，如果想尝鲜使用

RabbitMQ

连接器，可以选用下面的两种方式之一：

• 选用v1.1.5-alpha-1版本，但是无法修改RabbitMQ的port属性，默认为5672。
• 基于master分支自行构建Canal。

目前，

Canal

项目的活跃度比较高，但是考虑到功能的稳定性问题，笔者建议选用稳定版本在生产环境中实施，当前可以选用

v1.1.4

版本，**「本文的例子用选用的就是

v1.1.4

版本，配合

Kafka

连接器使用」**。

Canal

主要包括