早期阿里巴巴因为杭州和美国双机房部署,存在跨机房同步的业务需求,实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始,业务逐步尝试数据库日志解析获取增量变更进行同步,由此衍生出了大量的数据库增量订阅和消费业务。

1. 概述

Canal是阿里开源的一款基于 Mysql 数据库 binlog 的增量订阅和消费组件,通过它可以订阅数据库的binlog日志,然后进行一些数据消费,如数据镜像、数据异构、数据索引、缓存更新等。相对于消息队列,通过这种机制可以实现数据的有序化和一致性。

Canal Server 能够解析 MySQL binlog 并订阅数据更改,而 Canal Client 可以实现将更改广播到任何地方,例如数据库和Apache Kafka。

它具有以下功能:

  • 支持所有平台。
  • 支持由 Prometheus 提供支持的细粒度系统监控。
  • 支持通过不同方式解析和订阅 MySQL binlog,例如通过GTID。
  • 支持高性能数据同步。
  • Canal Server和Canal Client都支持HA / Scalability,由Apache ZooKeeper提供支持
  • Docker支持。

缺点:

不支持全量更新,只支持增量更新。

2. 工作原理

canal 的工作原理就是把自己伪装成 MySQL slave,模拟 MySQL slave 的交互协议向 MySQL Mater 发送 dump 协议,MySQL mater 收到 canal 发送过来的 dump 请求,开始推 送binary log 给 canal,然后 canal 解析 binary log,再发送到存储目的地,比如 MySQL,Kafka,Elastic Search 等等。

截屏2021-10-18 下午7.05.21
  • canal 模拟 MySQL slave 的交互协议,伪装自己为 MySQL slave ,向 MySQL master 发送dump 协议
  • MySQL master 收到 dump 请求,开始推送 binary log 给 slave (即 canal )
  • canal 解析 binary log 对象(原始为 byte 流)
截屏2021-10-18 下午7.03.15

3. canal 能做什么

早期阿里巴巴因为杭州和美国双机房部署,存在跨机房同步的业务需求,实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始,业务逐步尝试数据库日志解析获取增量变更进行同步,由此衍生出了大量的数据库增量订阅和消费业务。

基于日志增量订阅和消费的业务包括

  • 数据库镜像
  • 数据库实时备份
  • 索引构建和实时维护(拆分异构索引、倒排索引等)
  • 业务 cache 刷新
  • 带业务逻辑的增量数据处理

4. Canal HA 机制

线上服务的稳定性极为重要,Canal 支持HA的,其实现机制也是依赖Zookeeper来实现的,与HDFS的HA类似。

Canal 的 HA 分为两部分,Canal server 和 Canal client 分别有对应的 HA 实现。

  • Canal Server

    为了减少对 mysql dump 的请求,不同 server 上的 instance 要求同一时间只能有一个处于 running,其他的处于standby 状态。

    1. canal server要启动某个canal instance时都先向zookeeper进行一次尝试启动判断 (实现:创建EPHEMERAL节点,谁创建成功就允许谁启动)

    2. 创建zookeeper节点成功后,对应的canal server就启动对应的canal instance,没有创建成功的canal instance就会处于standby状态

    3. 一旦zookeeper发现canal server A创建的节点消失后,立即通知其他的canal server再次进行步骤1的操作,重新选出一个canal server启动instance.

    4. canal client每次进行connect时,会首先向zookeeper询问当前是谁启动了canal instance,然后和其建立链接,一旦链接不可用,会重新尝试connect.

  • Canal Client

    为了保证有序性,一份 instance 同一时间只能由一个 canal client 进行 get/ack/rollback 操作,否则客户端接收无法保证有序。

    Canal Client的方式和canal server方式类似,也是利用zookeeper的抢占EPHEMERAL节点的方式进行控制

依赖 Zookeeper 的特性

  • Watcher 机制
  • EPHEMERAL 节点(和session生命周期绑定)
截屏2021-10-18 下午7.19.25
  1. Canal server 要启动某个 canal instance 时都先向 zookeeper 进行一次尝试启动判断 (实现: 创建EPHEMERAL节点,谁创建成功就允许谁启动)。
  2. 创建 ZooKeeper 节点成功后,对应的 Canal server 就启动对应的 Canal instance,没有创建成功的 Canal instance 就会处于 standby 状态。
  3. 一旦 ZooKeeper 发现 Canal server A 创建的节点消失后,立即通知其他的 Canal server 再次进行步骤1的操作,重新选出一个 Canal server 启动instance。
  4. Canal client 每次进行 connect 时,会首先向 ZooKeeper 询问当前是谁启动了 Canal instance,然后和其建立链接,一旦链接不可用,会重新尝试 connect。

5. 总结

canal 对业务代码没有侵入,因为是基于监听binlog日志去进行同步数据的。实时性也能做到准实时

实际开发中一般是配置 MQ 模式,配合 Kafka,canal会把数据发送到 MQ 的 topic 中,然后通过消息队列的消费者进行处理

截屏2021-10-18 下午7.09.37