文章目录
一、整体设计
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 接口介绍
CanalConnector 的作用是与服务端进行交互，支持连接、订阅、获取数据、回滚、
2205
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
