阿里开源：mysql binlog 数据组件canal使用场景

背景

在通常的业务发展过程中，我们通常会有一些针对数据的变化进行业务处理的需求。

先做一个假设：我们的订单数据在Mysql生产数据库中，在线上订单数据不断变更的同时，我们希望这些变化能够同步到其他的业务系统中。

比如

1. 我们希望Mysql订单数据能够同步到Sqlserver或oracle数据库中
2. 我们希望订单数据的变更能够作为一个触发事件来更新线上的分布式缓存
3. 我们希望订单数据的特定变更能够触发其他业务，异与MQ的另外一种实现
4. 我们希望线上的数据变更能够实时的反映到搜索引擎的索引当中去
5. 我们希望对特定数据做一些备份

以上的需求以前通常是通过数据库的触发器来实现。但坏处显而易见：直接跟生产数据库强关联，抢占了数据库宝贵的资源，更有可能造成生产数据库的不稳定，所以使用触发器不是一个长远的解决方案。

阿里为了解决这个问题，开始用新的思路和方法，通过解析mysql的日志获取增量数据，因而诞生出了canal

以下内容来自https://github.com/alibaba/canal

canal是什么

阿里开源出的一个基于Mysql的日志增量变更的订阅消费组件。

基于日志增量变更的订阅消费的业务包括

• 数据库镜像（数据数据安全方面）
• 数据库实时备份（创建mysql的slave库）
• 索引构建和实时维护(拆分异构索引、倒排索引等)
• 业务 cache 刷新（分布式大并发的缓存更新）
• 带业务逻辑的增量数据处理（其他需要监控增量数据的业务需求）

canal工作原理

Mysql主从复制原理

• 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 流)

binlog的数据异构方式

mysql的主从复制就是slave通过解析binlog实现的。
canal的工作原理就是把自己伪装成master的一个slave，可以说canal就是将mysql中的一部分功能独立出来做了一层封装。

通过canal进行数据增量的关联业务，能够比较好的保证数据的一致性，在这方面是强于通常的MQ方式的。 但是它也有缺点，无法达到MQ的吞吐量和灵活，而且实现复杂度也高。
但两者并不冲突，还可以配合使用。

通过binlog实现为我们提供了另外一个解藕不同业务的新思路。