Canal架构以及使用规范- 惊觉

Canal架构以及使用规范

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

所以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 进行提交，避免误操作