数据同步中间件canal架构设计

MySQL主从同步原理

主从复制的过程如下图所示：

1. Master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events，可以通过show binlog events进行查看）；
2. Slave（I/O thread）从Master主库拉取binlog数据，将它拷贝到Slave的中继日志(relay log)中；
3. Slave（SQL thread）重做中继日志中的事件，更新从库上的数据；

canal的工作原理

原理相对比较简单：

1. canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议
2. mysql master收到dump请求，开始推送binary log给slave(也就是canal)
3. canal解析binary log对象(原始为byte流)

架构设计

个人理解，数据增量订阅与消费应当有如下几个点：

• 增量订阅和消费模块应当包括binlog日志抓取，binlog日志解析，事件分发过滤（EventSink），存储（EventStore）等主要模块。
• 如果需要确保HA可以采用Zookeeper保存各个子模块的状态，让整个增量订阅和消费模块实现无状态化，当然作为consumer(客户端)的状态也可以保存在zk之中。
• 整体上通过一个Manager System进行集中管理，分配资源。

可以参考下图：

canal架构设计

说明：

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

instance模块：

• eventParser (数据源接入，模拟slave协议