Canal架构以及使用规范

一、Canal的作用

相关文档：GitHub - alibaba/canal: 阿里巴巴 MySQL binlog 增量订阅&消费组件

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

所以canal是基于MySQL的主从复制原理上处理的，这使得我们的主库一定要开启主从复制功能才能使用canal，以及主库的binlog 格式为：

• 查看当前数据库的binlog格式

二、Canal的整体架构

目前Canal分为三个部分：

• server 代表一个 canal 运行实例，对应于一个 jvm

• instance 对应于一个数据队列 （1 个 canal server 对应 1…n 个 instance )

• instance 下的子模块

  • eventParser: 数据源接入，模拟 slave 协议和 master 进行交互，协议解析
  • eventSink: Parser 和 Store 链接器，进行数据过滤，加工，分发的工作
  • eventStore: 数据存储
  • metaManager: 增量订阅 & 消费信息管理器
    
    EventParser 在向 MySQL 发送 dump 命令之前会先从 Log Position 中获取上次解析成功的位置(如果是第一次启动，则获取初始指定位置或者当前数据段 binlog 位点)。mysql 接受到 dump 命令后，由 EventParser 从 mysql 上 pull binlog 数据进行解析并传递给 EventSink(传递给 EventSink 模块进行数据存储，是一个阻塞操作，直到存储成功 )，传送成功之后更新 Log Position。流程图如下：
    

• EventSink 起到一个类似 channel 的功能，可以对数据进行过滤、分发/路由(1:n)、归并(n:1)和加工。EventSink 是连接 EventParser 和 EventStore 的桥梁。

• EventStore 实现模式是内存模式，内存结构为环形队列，由三个指针(Put、Get 和 Ack)标识数据存储和读取的位置。

• MetaManager 是增量订阅 &消费信息管理器，增量订阅和消费之间的协议包括 get/ack/rollback，分别为：

  • Message getWithoutAck(int batchSize)，允许指定 batchSize，一次可以获取多条，每次返回的对象为 Message，包含的内容为：batch id[唯一标识]和 entries[具体的数据对象]

  • void rollback(long batchId)，顾名思义，回滚上次的 get 请求，重新获取数据。基于 get 获取的 batchId 进行提交，避免误操作

  • void ack(long batchId)，顾名思议，确认已经消费成功，通知 server 删除数据。基于 get 获取的 batchId 进行提交，避免误操作

三、Canal的使用

admin

四、目前Canal的使用规范