canal与mysql高可用_canal 高可用介绍（4）

概述

这篇文章的目的是为了讲清楚canal的 HA 机制，至于什么是 HA 机制直接套用canal官网原话，因为我自认为没法描述的更好。而我直接从代码的角度去分析如何实现 HA 的，其实也就是 zookeeper 的分布式锁的使用方法。

摘录自官网的一段原话：

canal的 HA 分为两部分，canal server 和canal client 分别有对应的 ha 实现：

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

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

canal HA 架构图

canal-ha 说明图

说明

图片来自官网的剪切，讲述的很清楚，就不再多说什么了，后面会基于这个图从代码角度展开讲解。

canal server HA

canal server 的 HA 是其实我觉得从我自己的理解应该分为两个角度去讲解，一个是在启动的时候抢占并负责启动提供服务，另外一个是在发生 fail-over 后抢占并负责启动提供服务。

能把这两个过程讲解清楚我觉得就够了，就能理解 server 的 HA 机制了，也基本了解了如何通过 zookeeper 去实现互斥锁。

最后我们需要问自己的一个问题，就是发生 HA 切换的时候状态数据同步在两个切换的 server 之间进行同步呢，很简单，因为我们的数据都是记录在 zookeeper 上的。

server 启动 HA

server 在启动过程中，通过以下几步来实现抢占服务启动，入口类在 CanalController。

1、对临时节点(/otter/canal/destinations/xxxx/running)进行监听。

2、通过创建临时节点来抢占锁，成功就提供服务。

3、抢占锁成功后启动 embededCanalServer 开始提供服务。

4、创建的临时节点内部将自己的 ip+port 暴露出去给 client 使用。

start-ha-1

说明

启动服务的入口函数，别看是 runningMonitor，其实是内部负责启动 canal instance 实例的。

start-ha-2

说明

这里最重要的一个点就是对 canal 的临时节点监控用于在 fail-over 的时候能够感知到并及时启动 stand-by 的 canal server 提供服务。

start-ha-3

说明

负责创建临时节点来确认自己是否能够提供服务，这其实通过 zookeeper 的特性来实现的。

start-ha-4

说明

真正启动 canal instance 的过程，负责同步 mysql 的数据到 canal instance。

server fail-over ha

server 在 fail-over 过程能够及时发现并完成切换的原因是通过 zookeeper 的 watch 机制来实现，如果 watch 的节点消失了那么其他监听的 canal server 都能感知到并发起新一轮的抢占并提供服务。

需要区分两个 zookeeper 事件，分别是节点内容变更事件、节点删除事件，下面有具体说明。

关键字：zookeeper 的 watch 机制，通知，重新抢占。

fail-over-1

说明

这里区分了两种情况，节点内容变更事件、节点本身消失事件。对于这两种情况区分简单区分一下进行说明。我估计很多人跟我的疑惑一样，为啥要区分这两个事件呢，其实我的猜测是如果节点删除了说明这个服务停止了跟 mysql 的同步也就结束了，但是如果节点内容变更了，可能因为其他一些原因，譬如我们手动修改 zk 节点内容之类的，这个时候我们需要处理连接释放的过程。

节点本身消失处理是 handleDataDeleted 函数内部的操作，可以看出来其实就做一件事情，重新开始新一轮的抢占，initRunning 就是我们刚刚讲的抢占逻辑，可以翻看 start-ha-3 这个图片。唯一的区别是节点消失事件前提供服务的如果是自身就具有优先抢占的权利，否则就随机进行个 delay 操作避免同时大面积并发抢占。

我们重点关注下节点内容变更的事件吧，之所以需要额外关注这个事件是因为中间涉及到如果是如果变更前是自身就需要释放连接资源。

资源释放过程

canal server release – 1

说明

在收到节点内容变更事件后就开始进入资源释放过程

canal server release – 2

说明

停止 canal 的 embededCanalserver 的服务，结束从 mysql 的数据同步。

canal client HA

整体来说，canal client 的 HA 和 canal server 的 HA 机制是一模一样的，它的实现逻辑其实在创建 cluster client 的时候用的封装 zookeeper 的客户端，然后 zookeeper 的客户端去检测 canal server 节点内容的变化并重新初始化连接而已。

client cluster -1

说明

这个地方很明显看出来，我们首先连接的 zookeeper，原因应该很清楚，因为我们需要从 zookeeper 获取提供服务的 canal server 的地址，在/otter/canal/destinations/destination/running 节点去获取。

client cluster-2

client cluster-3

说明

这部分其实就是 client 和 zookeeper 交互的部分，负责实时感知节点变化并重新初始化连接，保证 client 端的 HA。

作者：晴天哥 _374

链接：https://www.jianshu.com/p/0f580647905c

来源：简书

简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

露水湾 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权

转载请注明原文链接：canal 高可用介绍(4)