Apache Canal

定义

Apache Canal是以Java语言开发的、基于数据库增量日志解析的中间件，定位是提供增量数据的订阅与消费能力^[1]。它的核心工作对象是MySQL的二进制日志binlog，把其中记录的增删改操作解析成可理解的变更事件，再交给下游系统处理^[2]。它可以被视为一种变更数据捕获(CDC)工具，用于在异构数据源之间实现数据同步^[3]。

截至开源版本，Canal主要支持解析MySQL的binlog，源端MySQL版本覆盖5.1.x、5.5.x、5.6.x、5.7.x和8.0.x^[1]。项目采用客户端与服务端分离的模式，两者之间使用protobuf 3.0作为交互协议，客户端可以用不同语言实现各自的消费逻辑^[4]。

原理

Canal的工作方式建立在对MySQL主从复制机制的模仿之上。在常规的主从复制中，主库把数据变更写入二进制日志，从库把主库的二进制日志事件拷贝到本地的中继日志，再重放这些事件使自身数据与主库保持一致^[1]。Canal没有真正复制数据，而是模拟MySQL从库的交互协议，把自己伪装成一个从库，向主库发送dump请求；主库收到请求后开始推送二进制日志，Canal再将原始为字节流的日志对象解析出来。

从组件结构看，一个server代表一个Canal运行实例，对应一个JVM；一个instance对应一个数据队列，一个server可以包含多个instance，每个instance通常对应一个MySQL实例^[5]。instance内部由四部分组成：eventParser负责接入数据源、模拟从库协议与主库交互并解析协议，eventSink负责数据的过滤、加工与分发，eventStore负责存储数据，metaManager负责管理增量订阅与消费的信息^[5]。数据在其中的流转顺序是eventParser、eventSink到eventStore^[6]。

由于Canal需要解析日志内容以还原每行数据的变更，源数据库的binlog格式通常要求设置为ROW模式；在该模式下，日志会记录每行记录的变化情况，而不只是记录执行的SQL语句^[2]。使用前一般需要在MySQL中开启binlog并创建具备REPLICATION SLAVE、REPLICATION CLIENT权限的账号供Canal连接使用^[3]。

Canal的高可用依赖分布式协调服务ZooKeeper：多个Canal server上的同名instance在同一时间只允许一个处于运行状态，其余处于待命状态，通过抢占临时节点的方式选出实际运行的实例，该实例失效后由其他server重新接管^[5]。客户端连接时也会先询问ZooKeeper当前由哪个实例在提供服务^[5]。

发展历程

Canal的产生源于阿里巴巴B2B业务的实际需求。早期阿里巴巴在杭州和美国两地部署机房，存在跨机房同步数据的需求，当时的实现方式主要基于数据库触发器获取增量变更^[1]。从2010年开始，阿里系公司逐步尝试通过解析数据库日志来获取增量变更并完成同步，由此衍生出增量订阅与消费的业务方向^[2]。

Canal最初是阿里巴巴异地数据库同步框架Otter的组成部分之一^[2]。项目代码托管在GitHub上，仓库创建于2013年1月13日^[7]。其1.1.x版本在性能与功能上有较大改进，包括原生支持Prometheus监控、原生支持Kafka消息投递、支持阿里云RDS的binlog订阅以及提供Docker镜像^[4]。

1.1.4版本引入了canal-admin工程，提供面向网页界面的动态管理能力，支持配置、任务和日志的在线运维^[4]。此后项目持续迭代，2024年发布了1.1.8系列的多个测试版本，2025年1月16日发布1.1.8稳定版本，该版本在语法关键字层面兼容MySQL 8.4，并支持MySQL的SSL交互协议^[8][9]。项目采用Apache License 2.0许可协议^[7]。

应用

Canal的典型用途是数据异构，即把同一份数据以不同组织方式同步到多个存储系统中。例如在电商场景中，订单数据可以按用户维度分库写入主库，再通过Canal监听binlog把数据同步到按商家维度分库的另一套库中，从而避免跨库关联查询。类似的跨存储同步还包括把MySQL数据同步到Redis等缓存、同步到Elasticsearch等搜索引擎，以及同步到消息队列后由下游消费^[10]。

在实时性要求较高的场景中，Canal可用于数据库镜像、数据库实时备份、索引构建与实时维护、业务缓存刷新，以及带业务逻辑的增量数据处理^[1]。当数据库发生变更时，系统可以通过binlog触发缓存或搜索索引的增量更新，也可以在商品等数据变更后把变更内容写入消息队列，用于向依赖该数据的其他系统下发任务^[5]。

部署上，Canal可以作为独立服务运行，也可以把解析结果投递到Kafka、RocketMQ、RabbitMQ等消息中间件，借助消息队列的多语言能力对接不同技术栈的消费方^[4]。阿里云的RDS、Elasticsearch等产品文档中提供了将Canal与相应云服务对接的配置方式^[11]。阿里云的DRDS、TDDL二级索引与小表复制等功能也由Canal提供支持^[7]。

局限

Canal只能进行增量同步，无法直接同步历史数据。它通过订阅binlog并解析某个位点之后的变更事件来工作，不会主动扫描表中的已有数据，因此在做数据迁移或搭建新下游时，需要先自行完成一次全量导入，再让Canal从记录的位点开始消费增量，否则原有数据不会被捕获^[12]。

在数据源支持范围上，Canal的binlog解析针对MySQL设计，源端只支持MySQL(以及MariaDB)的日志格式，源库如果是Oracle等其他数据库则无法直接使用^[13]。对于DDL变更，Canal只负责解析并推送相应事件，目标库的表结构调整需要由消费方自行编写逻辑处理，若处理遗漏可能导致后续数据同步失败^[13]。

Canal的投递语义通常是至少一次，服务重启或重新连接时可能重放一段binlog，因此消费端需要具备幂等能力，例如采用按主键更新插入、去重删除或版本号比对等方式防止旧事件覆盖新数据^[14]。其数据链路从binlog经解析到下游消费存在延迟，属于最终一致而非强一致，不适合替代需要强一致性的核心事务链路^[14]。此外，遇到单次影响百万行的大事务时，事件量激增可能冲垮下游，需要对大事务拆分并对消费端限流和监控积压情况^[14]。

参见

• MySQL —— Canal 解析的增量日志来源，其二进制日志机制是 Canal 工作的前提。

• ZooKeeper —— Canal 实现服务端与客户端高可用时依赖的分布式协调服务。

• Kafka —— Canal 常将解析后的变更记录投递到的消息中间件。

• Elasticsearch —— 常见的下游目标之一，通过 Canal 实现搜索索引的增量维护。

• 变更数据捕获 —— Canal 所属的技术类别，指捕获数据库变更并向外发布的方法。

• Flink CDC —— 另一类支持全量与增量一体化同步的变更数据捕获方案。