绑定完请刷新页面
取消
刷新

分享好友

×
取消 复制
从零单排canal 01」 canal 10分钟入门(基于1.1.4版本)
2020-06-04 10:00:33


1.简介

canal [kə'næl],译意为水道/管道/沟渠,主要用途是基于 MySQL 数据库增量日志解析,提供增量数据 订阅 和 消费。应该是阿里云DTS(Data Transfer Service)的开源版本。

2.提供的能力

Canal与DTS提供的功能基本相似:

1)基于Mysql的Slave协议实时dump binlog流,解析为事件发送给订阅方。

事件格式为(伪代码):

Eevnt {
    Header { logfileName [binlog文件名]
logfileOffset [binlog position]
executeTime [binlog里记录变更发生的时间戳]
schemaName [数据库实例]
tableName [表名]
eventType [insert/update/delete类型]
}
entryType [事务头BEGIN/事务尾END/数据ROWDATA]
storeValue [byte数据,可展开,对应的类型为RowChange]
isDdl [是否是ddl变更操作,比如create table/drop table]
sql [具体的ddl sql]
rowDatas [具体insert/update/delete的变更数据,可为多条,1binlog event事件可对应多条变更,比如批处理]
beforeColumns [Column类型的数组]
afterColumns [Column类型的数组]
}
Column {
index [column序号]
sqlType [jdbc type]
name [column name]
isKey [是否为主键]
updated [是否发生过变更]
isNull [值是否为null]
value [具体的值]
}

2)单Canal instance,单DTS数据订阅通道均只支持订阅一个RDS,提供给一个消费者。

3)可以使用canal-client客户端进行消息消费。

4)也可以通过简单配置,也可以不需要自行使用canal-client消费,可以选择直接投递到kafka或者RocketMQ集群,用户只需要使用消息队列的consumer消费即可。

5)成功消费消息后需要进行Ack,以确保一致性,服务端则会维护客户端目前的消费位点。

3.工作原理

MySQL的主从复制分成三步:

  • master将改变记录到二进制日志(binary log)中(这些记录叫做二进制日志事件,binary log events,可以通过show binlog events进行查看);

  • slave将master的binary log events拷贝到它的中继日志(relay log);

  • slave重做中继日志中的事件,将改变反映它自己的数据。


canal 就是模拟了这个过程。

  • canal模拟 MySQL slave 的交互协议,伪装自己为 MySQL slave ,向 MySQL master 发送 dump 协议;

  • MySQL master 收到 dump 请求,开始推送 binary log 给 slave (即 canal );

  • canal 解析 binary log 对象(原始为 byte 流);


4. canal 架构

4.1 admin版本整体架构

canal 1.1.4开始支持admin管理,通过canal-admin为canal提供整体配置管理、节点运维等面向运维的功能,提供相对友好的WebUI操作界面,方便更多用户快速和安全的操作,替代了过去繁琐的配置文件管理。

整体部署架构如下。


  • 多个canal-server可以组成集群模式,每个instance任务通过zookeeper在集群中实现高可用

  • 通过多个集群,可以实现同步资源的物理隔离

  • 可以直接抓取消费投递MQ,可以实现生产/消费解耦、消息堆积、消息回溯

  • 可以抓取消费投递给canal-client,在用户的服务中进行消息处理,减少中间过程

4.2 canal-server架构


说明:

  • 每个集群可以由多个server组成;

  • 每个server代表一个canal-server运行实例jvm;

  • 每个server上可以运行一个或多个Instance;

  • 每个Instance对应于一个数据队列,是真正的变更抓取的实体 

1)instance模块

  • EventParser :数据源接入,模拟MySQL slave协议从master上dump binlog,并进行解析

  • EventSink :对dump的数据进行过滤、加工、分发,连接Parser和Store

  • EventStore :对sink模块处理后的数据进行临时存储

  • MetaManager:元数据管理器

2)EventParser子模块

主要有两个核心组件组成:

  • CanalLogPositionManager:用来记录新解析成功的binlog position信息,在canal重启后,作为起始位点

  • CanalHAController:支持Mysql主备,基于Heartbeat判断当前数据库连接的有效性,一旦主库失去心跳,就切换连接备库

EventParser从CanalHAController确定连接mysql的位置,然后通过LogPositionManager确定binlog解析位点的起点,后便通过dump协议拉取binlog进行解析,把解析后的消息存入EventSink

3)EventSink子模块

目前只有一个实现类GroupEventSink,用来把多个instance上的数据进行归并,主要用于分库后的多数据归并。

4)EventStore子模块

目前只实现了基于内存存储的MemoryEventStoreWIthBuffer,据说很多年前就声称要支持基于文件存储的实现,不过到现在还没有具体的实现类。

MemoryEventStoreWIthBuffer内部采用的是一个RingBuffer,我们可以理解为基于内存的高性能消息队列。如果使用canal-client直接消费canal-server的数据,那么只能通过这个消息队列做一定程度的消息堆积。

RingBuffer如下图所示:


  • Put : Sink模块进行数据存储的后一次写入位置

  • Get : 数据订阅获取的后一次提取位置

  • Ack : 数据消费成功的后一次消费位置

这些位点信息通过MetaManager进行管理。这也解释了为什么一个canal instance只能支撑一个消费者:EventStore的RingBuffer只为一个消费者维护信息。

4.3 客户端使用

数据格式已经在前文给出,Canal和DTS客户端均采取:

拉取事件 -> 消费 -> 消费成功后ACK

这样的消费模式,并支持消费不成功时进行rollback,重新消费该数据。

下面是一段简单的客户端调用实例(略去异常处理):

// 创建CanalConnector, 连接到localhost:11111

CanalConnector connector = CanalConnectors.newSingleConnector(new InetSocketAddress(AddressUtils.getHostIp(),11111), destination, "", "");

connector.connect(); // 连接

connector.subscribe(); // 开始订阅binlog

// 开始循环拉取

while (running) {

Message message = connector.getWithoutAck(1024); // 获取指定数量的数据

long batchId = message.getId();

for (Entry entry : message.getEntries()){

// 对每条消息进行处理

}

connector.ack(batchId); // ack

}

5.总结分析

5.1 优点

1)性能优异、功能全面

canal 1.1.x 版本(release_note),性能与功能层面有较大的突破,重要提升包括:

  • 整体性能测试&优化,提升了150%%。

  • 原生支持prometheus监控。

  • 原生支持kafka消息投递。

  • 原生支持aliyun rds的binlog订阅 (解决自动主备切换/oss binlog离线解析) (无法拒绝它的理由!)

  • 原生支持docker镜像。

2)运维方便

  • canal 1.1.4版本,迎来重要的WebUI能力,引入canal-admin工程,支持面向WebUI的canal动态管理能力,支持配置、任务、日志等在线白屏运维能力

  • Standalone的一体化解决方案,无外部服务依赖,运维更简单,在某种程度上也意味着更稳定。

  • 开箱即用,节约开发与定制成本。

  • 有良好的管理控制平台与监控系统(如果你已经有promethus监控,可以秒接canal监控)

3)多语言支持

  • canal 特别设计了 client-server 模式,交互协议使用 protobuf 3.0 , client 端可采用不同语言实现不同的消费逻辑

  • canal 作为 MySQL binlog 增量获取和解析工具,可将变更记录投递到 MQ 系统中,比如 Kafka/RocketMQ,可以借助于 MQ 的多语言能力

5.2 缺点

  • 单instance/订阅通道只支持订阅单个数据库,并只能支持单客户端消费。每当我们需要新增一个消费端->MySQL的订阅:对于Canal而言,就要给MySQL接一个“Slave”,可能会对主库有一定影响。

  • 消息的Schema很弱,所有消息的Schema均相同,客户端需要提前知道各个表消息的Schema与各字段的上下文才能正确消费。


好了,花了10分钟应该对canal有大致了解了,下一期,阿丸计划手把手教你搭建canal集群和admin管理平台。



分享好友

分享这个小栈给你的朋友们,一起进步吧。

阿丸笔记
创建时间:2020-05-13 10:42:09
微信公众号:阿丸笔记,获取新更新。 目前关注数据库中间件,包括MySQL、HBase、DataBus、数据库DevOps等。
展开
订阅须知

• 所有用户可根据关注领域订阅专区或所有专区

• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询

• 专区发布评论属默认订阅所评论专区(除付费小栈外)

栈主、嘉宾

查看更多
  • 阿丸笔记
    栈主

小栈成员

查看更多
  • 小雨滴
  • zergduan
  • 我没
  • qazwsxhai
戳我,来吐槽~