canal.client 源码分析

一、整体设计

1.1 功能概述

封装与 Canal Server 进行交互的客户端，提供两种实现给外部使用：

• 简单连接：直接通过 socket 与 server 进行交互，实现连接、订阅、批量获取、提交和回滚等操作。
• 有 HA 的 Cluster 连接：基于简单连接方式进行封装，通过 ZooKeeper 实现 client 端的 HA。

1.2 目录结构

其中 kafka 包和 rocketmq 包实现了接收到的消息直接发送到消息队列中，目前先重点关注与服务端的交互和消息的处理流程，后续会重点关注 kafka 包的实现，为目前生产上 C/S 端分离 ==> 集成 的改造做准备。

1.3 核心类

核心类类图

• ClientIdentity
  canal client 和 server 交互之间的身份标识，目前 clientId 写死为 1001（目前 canal server 上的一个 instance 只能有一个 client 消费，clientId 的设计是为 1 个 instance 多 client 消费模式而预留的，暂时不需要理会）。
• CanalConnector
  SimpleCanalConnector / ClusterCanalConnector：两种 connector 的实现，simple 针对的是简单的 IP 直连模式，cluster 针对多 IP 的模式，可依赖 CanalNodeAccessStrategy 进行 failover 控制。
• CanalNodeAccessStrategy
  SimpleNodeAccessStrategy / ClusterNodeAccessStrategy：两种 failover 的实现，simple 针对给定的初始 IP 列表进行failover选择，cluster 基于 ZooKeeper 上的 cluster 节点动态选择正在运行的 canal server。
• ClientRunningMonitor / ClientRunningListener / ClientRunningData
  client running 相关控制，主要为解决 client 自身的 failover 机制。canal client 允许同时启动多个 canal client，通过 running 机制，可保证只有一个 client 在工作，其他 client 做为冷备。当运行中的 client 挂了，running 会控制让冷备中的 client 转为工作模式，这样就可以确保 canal client 也不会是单点。保证整个系统的高可用性。ClientRunningData 对应 ZooKeeper 上的 /otter/canal/destinations/xxx/1001 节点数据。

二、类设计

2.1 CanalConnector

2.1.1 接口介绍

CanalConnec