学习笔记——Canal内部结构

Canal

Server

• server代表了一个canal的运行实例，为了方便组件化使用，特意抽象了Embeded(嵌入式) / Netty(网络访问)的两种实现
  • Embeded : 对latency和可用性都有比较高的要求，自己又能hold住分布式的相关技术(比如failover)
  • Netty : 基于netty封装了一层网络协议，由canal server保证其可用性，采用的pull模型，当然latency会稍微打点折扣，不过这个也视情况而定。(阿里系的notify和metaq，典型的push/pull模型，目前也逐步的在向pull模型靠拢，push在数据量大的时候会有一些问题)

Instance

• 整体设计

instance代表了一个实际运行的数据队列，包括了EventPaser,EventSink,EventStore等组件。

抽象了CanalInstanceGenerator，主要是考虑配置的管理方式：

• manager方式： 和你自己的内部web console/manager系统进行对接。(目前主要是公司内部使用)
• spring方式：基于spring xml + properties进行定义，构建spring配置。

eventParser

• 数据源接入，模拟slave协议和master进行交互，协议解析

  parser过程大致为：

  1. Connection获取上一次解析成功的位置 (如果第一次启动，则获取初始指定的位置或者是当前数据库的binlog位点)
  2. Connection建立起链接，发起BINLOG_DUMP请求
  3. MySQL开始推送Binary Log
  4. 通过Binary parser对接收到的Binary Log进行协议解析，补充一些特定的信息
     • 特定信息：字段名字，字段类型，主键信息，unsigned类型处理
  5. 传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功
  6. 存储成功后，定时记录Binaly Log位置

eventSink

• Parser和Store链接器，进行数据过滤，加工，分发的工作

  功能说明：

  1. 过滤：数据支持通配符的过滤模式，表名，字段内容等
  2. 路由/分发：解决1：n场景业务（一个Parser对应多个store）
  3. 归并：解决n：1场景业务（多个Parser对应一个store）
  4. 加工：在进入store之前进行额外的处理，如：join

eventStore

• 数据存储

  存储结构：

  1. 目前仅实现了Memory内存模式，后续计划增加本地file存储，mixed混合模式
  2. 借鉴了Disruptor的RingBuffer的实现思路
  3. 定义了3个cursor
     • Put : Sink模块进行数据存储的最后一次写入位置
     • Get : 数据订阅获取的最后一次提取位置
     • Ack : 数据消费成功的最后一次消费位置

• 实现说明：将RingBuffer拉直来看
  1. Put/Get/Ack cursor用于递增，采用long型存储
  2. buffer的get操作，通过取余或者与操作。(与操作： cusor & (size - 1) , size需要为2的指数，效率比较高)