场景

• 需要从 mysql 同步到 es，根据以上要求设计一套数据同步方案，要求延迟不大于3秒，需要考虑数据一致性问题以及查询效率
• 可以接受数据短暂不一致
• 数据量较多，对同步速度要求较高

方案 1：MQ 同步方案

流程图

优缺点

优点：

• 改造简单
• 基于 MQ 消费保障机制，不易出现数据丢失

缺点：

• 硬编码，依然存在业务代码耦合，业务增加发送 mq 代码
• 可能 MQ 接收到消息但是事务回滚了，或者保存到数据库但是没发送到 MQ，如果需要解决可能需要本地事务表等方案解决

方案 2：基于 Binlog 同步

Canal

实现细节

1. Canal 监听 binlog
2. Canal 根据一定的逻辑进行分发到多个 Partition，多消费者进行消费，提升消费速度
3. zookeeper 保证高可用
4. 主从切换时，虚拟 IP 转移到新的主库（MySQL + Keepalived 双主热备搭建）

优点

• 没有代码侵入、没有硬编码；
• 原有系统不需要任何变化，没有感知；
• 性能高；
• 业务解耦，不需要关注原来系统的业务逻辑。

Flink CDC

standalone 集群高可用性

实现细节

1. Flink standalone 集群高可用性使用 zookeeper 保证 jobManager 高可用
2. YARN 模式

1. 1. Flink JobManager 作为 YARN ApplicationMaster 运行，由 YARN 监控其健康状态。
   2. TaskManager 作为 YARN 上的容器（Containers）运行，当失败时，YARN 会重新启动容器，并加载检查点数据。

3. 重启之后使用 checkPoint 或 savePoint 进行故障恢复

1. 1. checkPoint 是定时生产快照，避免快照后又监听到一些语句，使用 upsert 的方式实现幂等，或者启用 kafka 事务
   2. savePoint 是手动创建的保存点

Flink 到 kafka 的精准一次

Cancal 对比 Flink CDC 的优势和缺点

优势：

• Cancal 1.16（最新的 release 版） 版本会丢数据
• Cancal 最新一版稳定版是 22 年 5 月，不知道是否还在维护
• Canal 不支持初始化全量同步，需要使用别的工具
• Flink CDC 可以自定义处理逻辑，使用 Java 代码的方式
• Flink CDC 可以借助 Flink 做 ETL，不需要别的组件

缺点：

• 虽然有 checkPoint，实现故障恢复，但单机的实现较麻烦，checkPoint 和高可用需要结合 Flink 使用
• Flink 有学习成本

方案3：数据传输 DTS

参考

如何保证kafka消息不丢失

Flink SQL CDC 实践以及一致性分析

JobManager 的高可用配置

Flink CDC 文章资料