【canal架构系列】canal整体架构

发表于 分类于 ， Valine：

本文参考资料

https://www.cnblogs.com/f-zhao/p/9112158.html

canal整体架构

说明：

  • server代表一个canal运行实例，对应于一个jvm
  • instance对应于一个数据队列 （1个server对应1..n个instance)，instance含有4个功能模块：
    • eventParser (数据源接入，模拟slave协议和master进行交互，协议解析)
    • eventSink (Parser和Store链接器，进行数据过滤，加工，分发的工作)
    • eventStore (数据存储)
    • metaManager (增量订阅&消费信息管理器)

eventparser模块介绍

整个parser过程大致可分为几步：

  • Connection获取上一次解析成功的位置（如果第一次启动，则获取初始制定的位置或者是当前数据库的binlog位点）
  • Connection建立连接，发生BINLOG_DUMP命令
  • Mysql开始推送Binary Log
  • 接收到的Binary Log通过Binlog parser进行协议解析，补充一些特定信息
  • 传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功
  • 存储成功后，定时记录Binary Log位置
    顺序图如下：
    ![](https://jxdw.github.io/img/canal/canal_parser_description.png）

eventsink模块

eventsink模块主要的工作：

  • 数据过滤：支持通配符的过滤模式，表名，字段内容等
  • 数据路由/分发：解决1:n (1个parser对应多个store的模式)
  • 数据归并：解决n:1 (多个parser对应1个store)
  • 数据加工：在进入store之前进行额外的处理，比如join

![](https://jxdw.github.io/img/canal/canal_sink_description.png）

eventstore模块

eventstore模块目前实现了：

  • Memory内存、
  • 本地file存储
  • 发送到mq

metaManager模块

metamaager保存信息如下：

  • destinations：保存着Client端信息，key为ClientId
  • batches：保存着Client对应的未ack的记录，key为ClientId
  • cursors：保存着Client对应的ack的位置，key为ClientId