1.简介

canal [kə'næl]，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据 订阅 和 消费。应该是阿里云DTS（Data Transfer Service）的开源版本。

2.提供的能力

Canal与DTS提供的功能基本相似：

1）基于Mysql的Slave协议实时dump binlog流，解析为事件发送给订阅方。

事件格式为(伪代码):

Eevnt {
    Header {        logfileName     [binlog文件名]
        logfileOffset   [binlog position]
        executeTime     [binlog里记录变更发生的时间戳]
        schemaName      [数据库实例]
        tableName       [表名]
        eventType       [insert/update/delete类型]
    }
    entryType           [事务头BEGIN/事务尾END/数据ROWDATA]
    storeValue          [byte数据,可展开，对应的类型为RowChange]
    isDdl               [是否是ddl变更操作，比如create table/drop table]
    sql                 [具体的ddl sql]
    rowDatas            [具体insert/update/delete的变更数据，可为多条，1个binlog event事件可对应多条变更，比如批处理]
    beforeColumns       [Column类型的数组]
    afterColumns        [Column类型的数组]
}
Column {
    index       [column序号]
    sqlType     [jdbc type]
    name        [column name]
    isKey       [是否为主键]
    updated     [是否发生过变更]
    isNull      [值是否为null]
    value       [具体的值]
}

2）单Canal instance，单DTS数据订阅通道均只支持订阅一个RDS，提供给一个消费者。

3）可以使用canal-client客户端进行消息消费。

4）也可以通过简单配置，也可以不需要自行使用canal-client消费，可以选择直接投递到kafka或者RocketMQ集群，用户只需要使用消息队列的consumer消费即可。

5）成功消费消息后需要进行Ack，以确保一致性，服务端则会维护客户端目前的消费位点。

3.工作原理

MySQL的主从复制分成三步：

• master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events，可以通过show binlog events进行查看）；
  
• slave将master的binary log events拷贝到它的中继日志(relay log)；
  
• slave重做中继日志中的事件，将改变反映它自己的数据。
  

canal 就是模拟了这个过程。

• canal模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送 dump 协议；
  
• MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )；
  
• canal 解析 binary log 对象(原始为 byte 流)；
  

4. canal 架构

4.1 admin版本整体架构

canal 1.1.4开始支持admin管理，通过canal-admin为canal提供整体配置管理、节点运维等面向运维的功能，提供相对友好的WebUI操作界面，方便更多用户快速和安全的操作，替代了过去繁琐的配置文件管理。

整体部署架构如下。

• 多个canal-server可以组成集群模式，每个instance任务通过zookeeper在集群中实现高可用
  
• 通过多个集群，可以实现同步资源的物理隔离
  
• 可以直接抓取消费投递MQ，可以实现生产/消费解耦、消息堆积、消息回溯
  
• 可以抓取消费投递给canal-client，在用户的服务中进行消息处理，减少中间过程
  

4.2 canal-server架构

说明：

• 每个集群可以由多个server组成；
  
• 每个server代表一个canal-server运行实例jvm；
  
• 每个server上可以运行一个或多个Instance;
  
• 每个Instance对应于一个数据队列，是真正的变更抓取的实体
  

1）instance模块

• EventParser ：数据源接入，模拟MySQL slave协议从master上dump binlog，并进行解析
  
• EventSink ：对dump的数据进行过滤、加工、分发，连接Parser和Store
  
• EventStore ：对sink模块处理后的数据进行临时存储
  
• MetaManager：元数据管理器

2）EventParser子模块

主要有两个核心组件组成：

• CanalLogPositionManager：用来记录最新解析成功的binlog position信息，在canal重启后，作为起始位点
  
• CanalHAController：支持Mysql主备，基于Heartbeat判断当前数据库连接的有效性，一旦主库失去心跳，就切换连接备库
  

EventParser从CanalHAController确定连接mysql的位置，然后通过LogPositionManager确定binlog解析位点的起点，最后便通过dump协议拉取binlog进行解析,把解析后的消息存入EventSink

3）EventSink子模块

目前只有一个实现类GroupEventSink，用来把多个instance上的数据进行归并，主要用于分库后的多数据归并。

4）EventStore子模块

目前只实现了基于内存存储的MemoryEventStoreWIthBuffer，据说很多年前就声称要支持基于文件存储的实现，不过到现在还没有具体的实现类。

MemoryEventStoreWIthBuffer内部采用的是一个RingBuffer，我们可以理解为基于内存的高性能消息队列。如果使用canal-client直接消费canal-server的数据，那么只能通过这个消息队列做一定程度的消息堆积。

RingBuffer如下图所示：

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

这些位点信息通过MetaManager进行管理。这也解释了为什么一个canal instance只能支撑一个消费者：EventStore的RingBuffer只为一个消费者维护信息。

4.3 客户端使用

数据格式已经在前文给出，Canal和DTS客户端均采取：

拉取事件 -> 消费 -> 消费成功后ACK

这样的消费模式，并支持消费不成功时进行rollback，重新消费该数据。

下面是一段简单的客户端调用实例（略去异常处理）：

// 创建CanalConnector， 连接到localhost:11111
CanalConnector connector = CanalConnectors.newSingleConnector(new InetSocketAddress(AddressUtils.getHostIp(),11111), destination, "", "");
connector.connect();    // 连接
connector.subscribe();  // 开始订阅binlog
// 开始循环拉取
while (running) {
    Message message = connector.getWithoutAck(1024); // 获取指定数量的数据
    long batchId = message.getId();
    for (Entry entry : message.getEntries()){
        // 对每条消息进行处理
    }
    connector.ack(batchId); // ack
}

5.总结分析

5.1 优点

1）性能优异、功能全面

canal 1.1.x 版本（release_note）,性能与功能层面有较大的突破,重要提升包括:

• 整体性能测试&优化,提升了150%。
  
• 原生支持prometheus监控。
  
• 原生支持kafka消息投递。
  
• 原生支持aliyun rds的binlog订阅 (解决自动主备切换/oss binlog离线解析)（无法拒绝它的理由！）
  
• 原生支持docker镜像。
  

2）运维方便

• canal 1.1.4版本，迎来最重要的WebUI能力，引入canal-admin工程，支持面向WebUI的canal动态管理能力，支持配置、任务、日志等在线白屏运维能力
  
• Standalone的一体化解决方案，无外部服务依赖，运维更简单，在某种程度上也意味着更稳定。
  
• 开箱即用，节约开发与定制成本。
  
• 有良好的管理控制平台与监控系统（如果你已经有promethus监控，可以秒接canal监控）
  

3）多语言支持

• canal 特别设计了 client-server 模式，交互协议使用 protobuf 3.0 , client 端可采用不同语言实现不同的消费逻辑
  
• canal 作为 MySQL binlog 增量获取和解析工具，可将变更记录投递到 MQ 系统中，比如 Kafka/RocketMQ，可以借助于 MQ 的多语言能力
  

5.2 缺点

• 单instance/订阅通道只支持订阅单个数据库，并只能支持单客户端消费。每当我们需要新增一个消费端->MySQL的订阅：对于Canal而言，就要给MySQL接一个“Slave”，可能会对主库有一定影响。
  
• 消息的Schema很弱，所有消息的Schema均相同，客户端需要提前知道各个表消息的Schema与各字段的上下文才能正确消费。