文章目录
- 产生背景
- 工作原理
- Canal的架构
产生背景
早期，阿里巴巴B2B公司因为存在杭州和美国双机房部署，存在跨机房同步的业务需求。不过早期的数据库同步业务，主要是基于trigger的方式获取增量变更，不过从2010年开始，阿里系公司开始逐步的尝试基于数据库的日志解析，获取增量变更进行同步，由此衍生出了增量订阅&消费的业务，从此开启了一段新纪元。
ps. 目前内部版本已经支持mysql和oracle部分版本的日志解析，当前的canal开源版本支持5.7及以下的版本(阿里内部mysql 5.7.13, 5.6.10, mysql 5.5.18和5.1.40/48)
工作原理
1.canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议
2.mysql master收到dump请求，开始推送binary log给slave(也就是canal)
3.canal解析binary log对象(原始为byte流)
4.canal把解析后的binary log以特性格式的消息推送到Kafka供下游消费
Canal的架构
说明
server代表一个canal运行实例，对应于一个jvm
instance对应于一个数据队列 （1个server对应1…n个instance)
instance模块
eventParser (数据源接入，模拟slave协议和master进行交互，协议解析)
eventSink (Parser和Store链接器，进行数据过滤，加工，分发的工作)
eventStore (数据存储)
metaManager (增量订阅&消费信息管理器)
