URL
date
AI summary
slug
status
tags
summary
type
前言
阅读本文之前,你需要对一些相关的背景知识有一定的了解,如:mysql的主从同步原理,Canal的使用场景等等。本文不会介绍这些内容,会将重点放在Canal的整体架构以及部署上(PS:以后如果有时间,也可以把上面的背景知识也单独出一些文章来介绍)。
本文期望以精炼的语言和相对清晰的架构图让你能对Canal有一个全面的了解,以及掌握部署一套基于Canal的异构数据同步链路的最佳实践。
核心组件
canal有4个核心组件,分别是:
- canal-instance
- canal-server(有些地方又称作 canal-deployer)
- canal-admin
- 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的运行模式,也对应了两种消费模式:
- TCP模式:通过自定义的tcp协议的client连接canal-server去消费
- 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同步链路的最佳实践
可以看到上图涵盖了前面介绍的核心组件。如果没找到的话,你再仔细看看(canal-client-adapter在图的中偏右下的地方哦)
为什么可以称之为“最佳实践”?因为这套方案相对来说比较完善,比如:
- 保证了监听及解析binlog的准确性,防止丢失
- 保证了canal-server以及MQ模式下内置client的高可用
- 增加了kafka作为消息队列,防止消费速度过慢对canal-server带来的影响,也把消费逻辑和canal-server解耦了
物理组件
- canal-admin
- canal-server
- zookeeper
- kafka
- canal-client-adapter
部署模式
部署canal-server的最佳实践,有以下2点
- 我们需要在配置文件中指定canal-admin的地址来启动canal-server。使用这种方式启动,后续可以通过canal-admin来统一管理canal-server和canal-instance的配置,并且修改后可以动态生效。
- 我们需要以MQ模式启动canal-server,并指定对应的mq类型,这里使用的是kafka,当然你也可以使用rocketmq等。再配置上指定的mq对应的配置
canal-server支持两种方式拉取配置文件
1. admin模式,带admin的,通过admin维护canal-server及canal-instance的配置
2. 本地文件模式,不带admin,通过本地配置文件维护canal-server及canal-instance的配置
zookeeper在整个最佳实践中起到的作用是
- 保证canal-server、MQ模式下内置client的高可用
- 保证同一个canal-instance同一时间就只能在一台canal-server上运行(当然这个也可能会有意外)
- 记录canal-client消费store的消费进度
部署流程
部署zookeeper、kafka
这块就不特别介绍了,也不属于本文的重点,相信你可以的
启动canal-admin
这部分可参考
只需要改一下下载的包的版本即可。
canal-admin启动之后,还需要做两步操作:
- 添加一个集群,一个集群代表一组canal-server,集群内部保证高可用
- 为这个集群添加一个主配置文件(通过载入模板再微调一下即可),这个集群里的所有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相关参数启动
其中,local模式的配置文件是最简的,几乎只有canal-admin相关的地址等信息。因为配合admin一起使用的场景,server的配置都不是在本地的,而是维护在canal-admin上的。
这里需要指定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的核心组件以及部署的最佳实践。其中,放出一张相对来说比较复杂的图,但是并没有细说,因为本文重点还是整体把握。后面的文章会围绕着这张图细说其中的每一个组件。
- 作者:黑微狗
- 链接:https://blog.hwgzhu.com/article/canal-core-introduction-and-deployment-best-practice
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。
相关文章