【Canal源码分析】整体架构

本文详解canal的整体架构。

一、整体架构

说明：

• server代表一个canal运行实例，对应于一个jvm
• instance对应于一个数据队列 （1个server对应1..n个instance)

instance模块：

• eventParser (数据源接入，模拟slave协议和master进行交互，协议解析)
• eventSink (Parser和Store链接器，进行数据过滤，加工，分发的工作)
• eventStore (数据存储)
• metaManager (增量订阅&消费信息管理器)

二、各模块架构

2.1 Parser

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

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

2.2 Sink

说明：

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

1 数据1:n业务 ：

为了合理的利用数据库资源， 一般常见的业务都是按照schema进行隔离，然后在mysql上层或者dao这一层面上，进行一个数据源路由，屏蔽数据库物理位置对开发的影响，阿里系主要是通过cobar/tddl来解决数据源路由问题。 所以，一般一个数据库实例上，会部署多个schema，每个schema会有由1个或者多个业务方关注。

2 数据n:1业务：

同样，当一个业务的数据规模达到一定的量级后，必然会涉及到水平拆分和垂直拆分的问题，针对这些拆分的数据需要处理时，就需要链接多个store进行处理，消费的位点就会变成多份，而且数据消费的进度无法得到尽可能有序的保证。 所以，在一定业务场景下，需要将拆分后的增量数据进行归并处理，比如按照时间戳/全局id进行排序归并.

2.3 Store

目前实现了Memory内存、本地file存储以及持久化到zookeeper以保障数据集群共享。
Memory内存的RingBuffer设计：

定义了3个cursor

• Put : Sink模块进行数据存储的最后一次写入位置
• Get : 数据订阅获取的最后一次提取位置
• Ack : 数据消费成功的最后一次消费位置

借鉴Disruptor的RingBuffer的实现，将RingBuffer拉直来看：

实现说明：

Put/Get/Ack cursor用于递增，采用long型存储
buffer的get操作，通过取余或者与操作。(与操作： cusor & (size – 1) , size需要为2的指数，效率比较高)