Canal架构以及使用规范

发布于:2024-07-11 ⋅ 阅读:(21) ⋅ 点赞:(0)

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的使用规范