基于 Canal 设计可扩展、高可用 binlog 同步集群

问题

binlog 同步组件，canal 使用是比较广泛的，canal 逻辑架构如图：

部署架构如图：

canal 基于主从模式，任务都运行在 master 中，client 从 master 拉取数据。在使用 canal server 的过程中，我们遇到了一些问题，例如扩展性不足，默认情况下，当任务流量变多变大时，单机无法支持大流量，要么增加主从集群，要么增加机器配置。

增加主从集群的问题：slave 机器很浪费。官方建议手动修改 running 配置，将 instance 平均分散。这样可以避免机器浪费。手工操作，不太友好，当流量突然变大时，无法应对。另外，操作麻烦，需要将任务从 a 集群迁移到 b 集群。

增加机器配置的问题：需要重启机器，重启前，需要转移任务到其他的机器，升级成功后，再手动转移回来（通过修改 zk

running 配置）这个对线上操作，不太友好。如果是临时流量，那就更危险了。

部署不太友好，基于 ECS 的部署方式很麻烦，不符合目前 k8s 动态扩缩容的设计。

不支持全量同步 + 增量同步，限流等逻辑。

设计

基于以上问题，我们想设计出一种支持以下特性的架构。

canal 任务可自动均匀分散在集群中，且集群机器互为主备。此需求解决大量任务运行+资源浪费+ 手动操作风险
该架构支持 k8s 集群，可快速扩容，升配。此需求解决大流量问题。
能够将指定的 canal 任务移动到指定机器。（虽然大部分任务流量不大，但需要考虑部分任务流量很大，需要单独高性能机器）
支持限流，暂停等操作。

如上图所示，我们定义了几个角色：

Manager，表示这个集群的管理者，用于调度 worker，并接收 worker 心跳
worker，用于执行 task 任务
task，包含 canal Server，canal client，binlog handler，能够连接 MySQL 服务器，拉取 binlog，并交给 binlog handler 处理，例如直接插入目标 MySQL，投递 Kafka，RocketMQ ，ES 等等。

高可用？

如何保证高可用？

当一个 worker 挂掉了，manager 收不到心跳，会将这个 worker 上任务，转移到其他的 worker 上（manager 会有一个 30s 间隔的定时任务扫描心跳），注意：task 有状态，状态保存在 Zookeeper 上。worker 宕机后，manager 会在其他的 worker 上启动 task，此时 task 会从 Zookeeper 上读取状态，这块逻辑和 canal 自身几乎相同。

扩展性？

当任务较多时，基于 k8s 基础之上，可立刻扩容机器，新机器会向 manager 发送心跳，manager 收到心跳后，则会将其他 worker 的任务，转移部分到新的 worker 上。

升配时，可先启动高配置 worker，manager 会将任务转移到高配置 worker，然后，k8s 系统会自动销毁低配置机器。此时，系统逻辑会回到高可用系统中。

部署？

worker 和 manager 本身基于 springCloud，无状态，可快速扩展。

增量 + 全量？

manager 系统已经实现该逻辑，当全量任务同步前，会先开启增量任务并暂时保存，然后开启全量任务，当全量任务结束时，会自动触发增量数据回放，回放结束后，则会回到纯增量逻辑

指定部署

指定将某个任务部署到指定机器，这个比较简单，manager 系统支持将指定任务名，分配到指定 ip 启动。

效果

上图显示了我们的系统，首页中，显示 worker 节点 8 个。task 35 个，qps 241，下面的 running worker list 显示了 worker 工作详情（QPS，task 数量），每个worker 的 task 数量基本相同，但也支持手动调节。

上图显示了 manager 支持自动重新负载所有 task。目的是让所有 task 均匀分布在运行的 worker 上。

下面的手动，显示了可以将某个指定 task 转移到指定机器上。

上图显示了如何创建一个任务。

上图显示了任务列表，可配置 QPS 进行限流，可早操作界面停止子任务。

目前，我司大部分同步任务，包括全量任务，增量任务，全量+增量任务，基本都使用该系统。业务场景包括，同步 MySQL 到 ES，数据库迁移，数据库同步，全链路压测影子库数据同步等。效果很好。

最后

感谢 canal 团队提供优秀的产品，使我们在 canal 基础上，开发了该系统。