一. 阿里canal工作原理
canal 是阿里的一款开源我的项目，纯Java开发。基于数据库增量日志解析，提供增量数据订阅&生产，目前次要反对了MySQL(也反对mariaDB)。
MySQL主备复制原理
- Master 将变更写入binlog日志；
- Slave 的 I/O thread 会去申请 Master 的binlog，并将失去的binlog写到本地的relay-log(中继日志)文件中；
- Slave 的 SQL thread 会从中继日志读取binlog，而后执行binlog日志中的内容，也就是在本人本地再次执行一遍SQL语句，从而使从服务器和主服务器的数据保持一致。
更多
MySQL 的 Binary Log 介绍
- http://dev.mysql.com/doc/refman/5.5/en/binary-log.html
- http://www.taobaodba.com/html/474_mysqls-binary-log_details.html
canal的工作原理
- canal 模仿 mysql slave 的交互协定，假装本人为 mysql slave，向 mysql master发送 dump 协定；
- mysql master 收到 dump 申请，开始推送binary log给 slave(也就是canal)
- canal 解析 binary log对象(原始为byte流)。
更多
对于 canal的具体介绍，能够拜访官网：https://github.com/alibaba/canal
二. 阿里canal的HA机制
1. 什么是HA机制
所谓HA（High Available），即高可用（7*24小时不中断服务）。
2. 单点故障
实现高可用最要害的策略是打消单点故障。比方Hadoop2.0之前，在HDFS集群中NameNode存在单点故障：
- NameNode机器发生意外，如宕机，集群将无奈应用；
- NameNode机器须要降级，包含软件、硬件降级，此时集群也将无奈应用。
3. Hadoop2.0引入HA机制
通过配置Active/Standby两个NameNodes实现在集群中对NameNode的热备来解决上述问题。
- 有一台节点是Active模式，也就是工作模式，其它的节点是 Standby（备用模式）；
- 干活的（Active模式的节点）如果挂了，就从备用模式的节点中选出一台顶上去。
更多
对于 Hadoop 的HA 机制的具体介绍，能够拜访：https://blog.csdn.net/pengjunlee/article/details/81583052
4. zookeeper的watcher和EPHEMERAL节点
zookeeper的watcher
watcher 机制波及到客户端与服务器（留神，不止一个机器，个别是集群）的两者数据通信与音讯通信：
更多
对于watcher 的具体介绍，能够拜访：https://www.jianshu.com/p/4c071e963f18
zookeeper的节点类型
EPHEMERAL节点是 zookeeper的长期节点，长期节点与session生命周期绑定，客户端会话生效后长期节点会主动革除。
更多
对于 zookeeper EPHEMERAL节点的具体介绍，能够拜访：
https://blog.csdn.net/randompeople/article/details/70500076
5. canal的 HA机制
整个 HA 机制的管制次要是依赖了zookeeper的上述两个个性：watcher、EPHEMERAL节点。canal的 HA 机制实现分为两局部，canal server 和 canal client别离有对应的实现。
canal server实现流程
- canal server 要启动某个 canal instance 时都先向 zookeeper 进行一次尝试启动判断 (实现：创立 EPHEMERAL 节点，谁创立胜利就容许谁启动）；
- 创立 zookeeper 节点胜利后，对应的 canal server 就启动对应的 canal instance，没有创立胜利的 canal instance 就会处于 standby 状态；
- 一旦 zookeeper 发现 canal server A 创立的节点隐没后，立刻告诉其余的 canal server 再次进行步骤1的操作，从新选出一个 canal server 启动instance；
- canal client 每次进行connect时，会首先向 zookeeper 询问以后是谁启动了canal instance，而后和其建设链接，一旦链接不可用，会从新尝试connect。
留神
为了缩小对mysql dump的申请，不同server上的instance要求同一时间只能有一个处于running，其余的处于standby状态。
canal client实现流程
- canal client 的形式和 canal server 形式相似，也是利用 zookeeper 的抢占EPHEMERAL 节点的形式进行管制
- 为了保障有序性，一份 instance 同一时间只能由一个 canal client 进行get/ack/rollback操作，否则客户端接管无奈保障有序。
三. canal的HA集群模式部署
1. canal下载地址
- 下载地址： https://github.com/alibaba/canal/releases
我应用的是 1.1.4 稳固版本。
2. mysql开启binlog
MySQL , 须要先开启 Binlog 写入性能，配置 binlog-format 为 ROW 模式，my.cnf 中配置如下：
[mysqld]log-bin=mysql-bin # 开启 binlogbinlog-format=ROW # 抉择 ROW 模式server_id=1 # 配置 MySQL replaction 须要定义，不要和 canal 的 slaveId 反复3. mysql受权账号权限
受权 canal 链接 MySQL 账号具备作为 MySQL slave 的权限, 如果已有账户可间接 grant：
CREATE USER canal IDENTIFIED BY 'canal'; GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%';-- GRANT ALL PRIVILEGES ON *.* TO 'canal'@'%' ;FLUSH PRIVILEGES;备注
能够通过在 mysql 终端中执行以下命令判断配置是否失效：
show variables like 'log_bin';show variables like 'binlog_format';4. 批改配置
canal 服务的部署其实特地简略，解压之后只需批改canal.properties、instance.properties这两个配置两个文件即可。
批改canal.properties中配置
//指定注册的zk集群地址canal.zkServers =127.0.0.1:2181,127.0.0.2:2181//HA模式必须应用该xml，须要将相干数据写入zookeeper,保证数据集群共享canal.instance.global.spring.xml = classpath:spring/default-instance.xml// 这个demo就是conf目录里的实例，如果要建别的实例'test'就建个test目录，把example外面的instance.properties文件拷贝到test的实例目录下就好了，而后在这里的配置就是canal.destinations = demo,testcanal.destinations = demo 批改demo.properties中配置
## mysql serverId , v1.0.26+ will autoGen# canal假装的mysql slave的编号，不能与mysql数据库和其余的slave反复canal.instance.mysql.slaveId=1003# 按需批改成本人的数据库信息# position infocanal.instance.master.address=10.200.*.109:3306# username/password 数据库的用户名和明码canal.instance.dbUsername=canalcanal.instance.dbPassword=canalcanal.instance.defaultDatabaseName = test5. 具体步骤
canal 的HA集群模式部署具体步骤，能够拜访：https://blog.csdn.net/XDSXHDYY/article/details/97825508
四. 通过实例感触zookeeper在HA机制中的作用
说了这么多，上面通过一个实例演示来感受一下 zookeeper 到底起了什么作用。
新建一个叫 'demo' 的实例：
$ cd /data/application/canal.deployer-1.1.4/conf$ cp -r example demo配置文件的批改能够参考第三局部贴出的配置。
环境
1. 版本
canal(1.1.4) + Zookeeper(3.4.6-78--1) 2. canal集群
canal server部署在两台机器上：
10.200.*.108 和 10.200.*.1093. zookeeper 集群
zookeeper部署在三台机器上：
10.200.*.109:2181,10.200.*.110:2181,10.200.*.111:2181从 zookeeper 中查看active节点信息
1. 应用 zkClient链接zookeeper server
$ ./zkCli.sh -server localhost:21812. 查看 zookeeper集群中，canal server的 active节点信息
[zk: localhost:2181(CONNECTED) 3] get /otter/canal/destinations/demo/running因为我还没有启动任何一台 canal server，所以查问的节点不存在。
别离启动多台机器上的canal server
别离登陆 108 和 109 两台机器，cd 到 canal 所在目录，命令行启动服务：
cd /data/application/canal.deployer-1.1.4sh bin/startup.sh景象一：只会有一个canal server的demo(instance名称)处于active状态
1. 持续查看zookeeper集群中，canal server的 active节点信息
从图中能够看出：
- 当前工作的节点为：10.200.*.109:11111。
2. 别离查看canal server的 启动日志
通过去 109 和 108 这两台机器上找到 canal server 启动日志，去验证一下下面的论断。
- 查看 109 机器的 canal server 启动日志：
[root@dc23x109-jiqi canal.deployer-1.1.4]# tail -f logs/demo/demo.log- 查看 108 机器的 canal server 启动日志：
从图中能够看出：
- 该log目录上面没有 demo目录，也就是说 108 机器上的 canal server 压根没有产生启动日志。
3. 论断
通过从 zookeeper 中查看节点信息和别离从两台 canal server 所在的机器上查看日志，能够得出如下论断：
- 109 和 108 上的 canal server 在接到
sh startup.sh命令后，都向 zookeeper 尝试创立 EPHEMERAL 节点，109的 canal server 创立胜利，因而启动的demo实例就处于active状态； - 108机器上的 canal server 创立 EPHEMERAL 节点失败，因而该 server 的 demo 实例就处于standby状态。
- 雷同名称的实例在散布在多个机器上的多个 server 里，同一时刻只会有一个实例处于 active 状态，缩小对mysql master dump 的申请。
景象二：敞开一个canal server后会从新选出一个canal server
1. 手动敞开109机器的canal server
cd /data/application/canal.deployer-1.1.4sh bin/stop.sh2. 查看zookeeper集群中，canal server的 active节点信息
从图中能够看出：
- 以后可用的 canal server 切换为：10.200.*.109:11111。
3. 论断
- 再次验证，canal server 启动时向 zookeeper 创立的节点就是长期节点，它与 session 生命周期绑定，当我手动执行敞开命令，客户端会话会生效，长期节点会主动革除；
- 一旦 zookeeper 发现 canal server 108 机器创立的节点隐没后，就会告诉其它的 canal server 再次进行向 zookeeper 尝试创立长期节点的操作，就会有新的 active 节点产生；
- 这不就是 HA 机制最外围的作用嘛，一个机器机器发生意外，如宕机，另外一个机器可能立马顶上，保障集群的失常应用，从而保障服务的高可用。
关注微信公众号
欢送大家关注我的微信公众号浏览更多文章：