canal实时同步中间件介绍及其配置

canal官网：https://www.gitmemory.com/alibaba/canal

github:https://github.com/alibaba/canal/wiki/Canal-Kafka-RocketMQ-QuickStart

一、canal是什么

Canal是阿里巴巴集团提供的一个开源中间件，能够通过解析数据库的增量日志，提供增量数据的订阅和消费功能。canal 作为 MySQL binlog 增量获取和解析工具，可将变更记录投递到 MQ 系统中，比如 Kafka/RocketMQ，可以借助于 MQ 的多语言能力(目前只支持kafka/RocketMQ)，当然也可丢到Elasticsearch中去

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

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

二、canal 工作原理

先理解MYSQL主从复制原理：

MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，可以通过 show binlog events 进行查看)
MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据

canal 工作原理：

canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议
MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )
canal 解析 binary log 对象(原始为 byte 流)

三、canal配置安装

我这边是选择推送binlog到kafka，下边介绍安装配置

官网的：

（1）Zookeeper：https://github.com/alibaba/canal/wiki/Zookeeper-QuickStart

（2）Kafka:https://github.com/alibaba/canal/wiki/Kafka-QuickStart

（3）canal.server：

1、到官网地址(release)下载最新压缩包,请下载 canal.deployer-latest.tar.gz

2、将canal.deployer 复制到固定目录并解压

mkdir -p /usr/local/canal
cp   canal.deployer-1.1.1.tar.gz   /usr/local/canal
tar -zxvf canal.deployer-1.1.1.tar.gz

3、配置修改参数

a.修改instance 配置文件 vi conf/example/instance.properties

对应ip 地址的MySQL 数据库需进行相关初始化与设置, 可参考 Canal QuickStart

#  按需修改成自己的数据库信息
#################################################
...
canal.instance.master.address=192.168.1.20:3306
# username/password,数据库的用户名和密码
...
canal.instance.dbUsername = canal
canal.instance.dbPassword = canal
...
# mq config
canal.mq.topic=example
# 针对库名或者表名发送动态topic
#canal.mq.dynamicTopic=mytest,.*,mytest.user,mytest\\..*,.*\\..*
canal.mq.partition=0
# hash partition config
#canal.mq.partitionsNum=3
#库名.表名: 唯一主键，多个表之间用逗号分隔
#canal.mq.partitionHash=mytest.person:id,mytest.role:id
#################################################

b.修改canal 配置文件vi /usr/local/canal/conf/canal.properties

# ...
# 可选项: tcp(默认), kafka, RocketMQ
canal.serverMode = kafka
# ...
# kafka/rocketmq 集群配置: 192.168.1.117:9092,192.168.1.118:9092,192.168.1.119:9092 
canal.mq.servers = 127.0.0.1:6667
canal.mq.retries = 0
# flagMessage模式下可以调大该值, 但不要超过MQ消息体大小上限
canal.mq.batchSize = 16384
canal.mq.maxRequestSize = 1048576
# flatMessage模式下请将该值改大, 建议50-200
canal.mq.lingerMs = 1
canal.mq.bufferMemory = 33554432
# Canal的batch size, 默认50K, 由于kafka最大消息体限制请勿超过1M(900K以下)
canal.mq.canalBatchSize = 50
# Canal get数据的超时时间, 单位: 毫秒, 空为不限超时
canal.mq.canalGetTimeout = 100
# 是否为flat json格式对象
canal.mq.flatMessage = false
canal.mq.compressionType = none
canal.mq.acks = all
# kafka消息投递是否使用事务
canal.mq.transaction = false

4、mq顺序性问题

binlog本身是有序的，写入到mq之后如何保障顺序的？

canal目前选择支持的kafka/rocketmq，本质上都是基于本地文件的方式来支持了分区级的顺序消息的能力，也就是binlog写入mq是可以有一些顺序性保障，这个取决于用户的一些参数选择
canal支持MQ数据的几种路由方式：单topic单分区，单topic多分区、多topic单分区、多topic多分区

canal.mq.dynamicTopic，主要控制是否是单topic还是多topic，针对命中条件的表可以发到表名对应的topic、库名对应的topic、默认topic name
canal.mq.partitionsNum、canal.mq.partitionHash，主要控制是否多分区以及分区的partition的路由计算，针对命中条件的可以做到按表级做分区、pk级做分区等

canal的消费顺序性，主要取决于描述2中的路由选择，举例说明：

（1）单topic单分区，可以严格保证和binlog一样的顺序性，缺点就是性能比较慢，单分区的性能写入大概在2~3k的TPS

（2）多topic单分区，可以保证表级别的顺序性，一张表或者一个库的所有数据都写入到一个topic的单分区中，可以保证有序性，针对热点表也存在写入分区的性能问题

（3）单topic、多topic的多分区，如果用户选择的是指定table的方式，那和第二部分一样，保障的是表级别的顺序性(存在热点表写入分区的性能问题)

（4）单topic、多topic的多分区，如果用户选择的是指定pk hash的方式，那只能保障的是一个pk的多次binlog顺序性 ** pk hash的方式需要业务权衡，这里性能会最好，但如果业务上有pk变更或者对多pk数据有顺序性依赖，就会产生业务处理错乱的情况. 如果有pk变更，pk变更前和变更后的值会落在不同的分区里，业务消费就会有先后顺序的问题

配置推送到kafka相对较简单，只需要在canal。properties中指定kakfa的ip即可，当前前提是需要先装好kafka以及zk

四、kafka的安装也是相对简单的，网上很多教程

推荐一个连接工具：offsetexplorer.exe。新建的主题信息可以在Topics里边可视化地查看，也支持在界面新增删除主题