URL
date
slug
status
tags
summary
type

前言

阅读本文之前,你需要对一些相关的背景知识有一定的了解,如:mysql的主从同步原理,Canal的使用场景等等。本文不会介绍这些内容,会将重点放在Canal的整体架构以及部署上(PS:以后如果有时间,也可以把上面的背景知识也单独出一些文章来介绍)。
本文期望以精炼的语言和相对清晰的架构图让你能对Canal有一个全面的了解,以及掌握部署一套基于Canal的异构数据同步链路的最佳实践。

核心组件

canal有4个核心组件,分别是:
  1. canal-instance
  1. canal-server(有些地方又称作 canal-deployer)
  1. canal-admin
  1. canal-client/canal-client-adapter

canal-instance

canal-instance是监听binlog、解析binlog、并把解析后的消息写入内存队列(store)的基本单元。
它是一个逻辑概念,运行于canal-server内。

canal-server(canal-deployer)

canal-server,又叫canal-deployer,负责canal-instance的运行。一个canal-server上可以运行多个canal-instance
canal-server有两种运行模式:TCP模式和MQ模式
  • TCP模式:canal-server会启动一个netty-server,客户端需要通过对应的协议去直接消费store里的数据
  • MQ模式:canal-server会启动一个隐式的client来消费store里的数据,并转存到MQ里
canal-server的运行模式,控制的是其上运行的所有canal-instance的运行模式。并且它一定程度上是由canal-client的消费模式决定的。

canal-admin

canal-admin是canal可视化的管理控制台,提供了canal-server以及canal-instance的管理(主要是配置管理以及启停管理)

canal-client

canal-client是canal-instance的消费端。根据canal-server的运行模式,也对应了两种消费模式:
  1. TCP模式:通过自定义的tcp协议的client连接canal-server去消费
  1. MQ模式:直接消费对应的MQ数据,只依赖MQ,不依赖canal

canal-client-adapter

canal-client-adapter,也属于canal-client,可以把它理解为官方提供的一些常见的异构数据同步通道的实现,比如同步到elasticsearch、hbase、mongodb、mysql、redis、kafka等。所以和canal-client一样,它支持TCP和MQ的消费模式。
当然如果预设的满足不了,那就还是需要自定义了,可以选择基于canal-client-adapter的框架自定义扩展,也可以自己消费对应的MQ或者store去实现。

部署Canal同步链路的最佳实践

一图胜千言,我画了一张图供大家参考,顺便引出下面的内容——部署Canal同步链路的最佳实践
notion image
可以看到上图涵盖了前面介绍的核心组件。如果没找到的话,你再仔细看看(canal-client-adapter在图的中偏右下的地方哦)
为什么可以称之为“最佳实践”?因为这套方案相对来说比较完善,比如:
  1. 保证了监听及解析binlog的准确性,防止丢失
  1. 保证了canal-server以及MQ模式下内置client的高可用
  1. 增加了kafka作为消息队列,防止消费速度过慢对canal-server带来的影响,也把消费逻辑和canal-server解耦了

物理组件

  • canal-admin
  • canal-server
  • zookeeper
  • kafka
  • canal-client-adapter

部署模式

部署canal-server的最佳实践,有以下2点
  1. 我们需要在配置文件中指定canal-admin的地址来启动canal-server。使用这种方式启动,后续可以通过canal-admin来统一管理canal-server和canal-instance的配置,并且修改后可以动态生效。
  1. 我们需要以MQ模式启动canal-server,并指定对应的mq类型,这里使用的是kafka,当然你也可以使用rocketmq等。再配置上指定的mq对应的配置
💡
canal-server支持两种方式拉取配置文件 1. admin模式,带admin的,通过admin维护canal-server及canal-instance的配置 2. 本地文件模式,不带admin,通过本地配置文件维护canal-server及canal-instance的配置
zookeeper在整个最佳实践中起到的作用是
  1. 保证canal-server、MQ模式下内置client的高可用
  1. 保证同一个canal-instance同一时间就只能在一台canal-server上运行(当然这个也可能会有意外)
  1. 记录canal-client消费store的消费进度

部署流程

部署zookeeper、kafka

这块就不特别介绍了,也不属于本文的重点,相信你可以的

启动canal-admin

这部分可参考
只需要改一下下载的包的版本即可。
canal-admin启动之后,还需要做两步操作:
  1. 添加一个集群,一个集群代表一组canal-server,集群内部保证高可用
  1. 为这个集群添加一个主配置文件(通过载入模板再微调一下即可),这个集群里的所有canal-server都共享这个配置文件。需要调整的配置项为
// zk地址 canal.zkServers = ${zk.addr} // 模式 tcp or 对应mq canal.serverMode = kafka // 使用kafka,要填上kafka的链接信息 kafka.bootstrap.servers = ${kafka.addr}

启动canal-server

canal-server其实现在叫canal-deployer,所以是在官网下载对应版本的canal-deployer,然后解压缩,执行启动脚本。启动脚本存在三种模式
  • 常规:使用canal.properties启动
  • local:使用canal_local.properties启动
  • debug:使用debug相关参数启动
notion image
其中,local模式的配置文件是最简的,几乎只有canal-admin相关的地址等信息。因为配合admin一起使用的场景,server的配置都不是在本地的,而是维护在canal-admin上的。
notion image
这里需要指定canal-admin地址相关的信息,还需要指定刚刚在canal-admin上添加的集群名称,让canal-server加入到这个集群中

添加canal-instance

这个也是载入模板之后做一些微调即可,主要的调整项就是需要监听的mysql的地址,用户名、密码
canal.instance.master.address=127.0.0.1:3307 canal.instance.dbUsername=root canal.instance.dbPassword=123456 // 需要订阅的表名 canal.instance.filter.regex=api_test.tag,test.z,api_test.student // 也可以全部订阅 # canal.instance.filter.regex=.*\\..*

部署canal-client-adapter

这个涉及到的东西比较多,我会单独启动另外一篇文章来详细讲解。

总结

本文主要介绍了Canal的核心组件以及部署的最佳实践。其中,放出一张相对来说比较复杂的图,但是并没有细说,因为本文重点还是整体把握。后面的文章会围绕着这张图细说其中的每一个组件。
 
带你了解MySQL binlog event关于怎么给blog搞一个自定义的域名