TL;DR
- 场景：需要实时同步 MySQL 增量数据到 Kafka、ClickHouse、Redis 等下游系统的中大型分布式架构
- 结论：Canal 通过解析 MySQL Binlog 实现低延迟、高吞吐的变更数据捕获，适合数据同步、缓存更新、拉链表构建等场景
- 产出：完整的 Canal 原理说明 + 部署配置指南 + 典型使用场景（拉链表、缓存更新、实时统计）
版本矩阵
| 功能 | 状态 | 说明 |
|---|---|---|
| MySQL Binlog 解析 | ✅ 已验证 | 支持 MySQL 全量和增量变更捕获 |
| PostgreSQL/Oracle CDC | ⚠️ 待验证 | 通过扩展插件支持非 MySQL 数据库 |
| Kafka 同步 | ✅ 已验证 | 增量数据写入 Kafka 消息队列 |
| Redis 缓存同步 | ✅ 已验证 | 数据库变更实时更新缓存 |
| ClickHouse/Hadoop 同步 | ✅ 已验证 | 实时数据仓库场景 |
| Flink 实时处理 | ✅ 已验证 | 作为 Flink 数据源进行流式处理 |
| 集群高可用部署 | ✅ 已验证 | 多节点负载均衡与故障切换 |
Canal 同步业务数据
环境准备
- Hadoop
- HBase
- Flink
- ClickHouse
- MySQL
- Canal
- Kafka
Canal 介绍
阿里巴巴 B2B 公司，由于业务的特性，卖家主要集中在国内，买家主要集中在国外，所以衍生出了杭州和美国异地机房的需求，从 2010 年开始，阿里系公司开始逐步的尝试基于数据库的日志解析，获取增量变更进行同步，由此衍生出了增量订阅、消费的业务。 Canal是用 Java 开发的基于数据库增量日志解析，提供增量数据订阅、消费的中间件。目前，Canal主要支持了 MySQL 的 Binlog 解析，解析完成后才利用 Canal Client 用来处理获得相关数据。（数据库同步需要案例的 otter 中间件，基于 Canal）。
Canal 的背景与初衷
在大规模互联网应用中，尤其是在像阿里巴巴这样的电商平台中，数据库的规模和复杂度通常非常高。为了提高数据的实时性和可用性，许多业务场景需要实时地同步数据库中的变化（如订单、用户数据等），并确保数据在多个系统之间一致。
Canal 的诞生，正是为了解决这一问题。通过 变更数据捕获（CDC） 技术，Canal 能够高效地监控并捕获数据库中的数据变动（如插入、更新、删除等操作），然后将这些变动实时同步到下游系统，如搜索引擎、数据仓库、缓存等。
Canal 的核心功能
变更数据捕获（CDC）
Canal 的核心功能是实现变更数据捕获，它通过 解析数据库日志（binlog） 的方式来获取数据库中的变化数据。Canal 支持 MySQL、PostgreSQL、Oracle 等数据库，并能够实时地捕获数据库的变化。
- 增量数据同步： 通过解析 binlog，Canal 能够识别出数据库的增量变化（插入、更新、删除等），并将这些变动同步到下游系统。
- 高效处理： Canal 对数据变更进行高效的捕获和同步，支持大规模的分布式部署，能够处理高并发、高吞吐量的场景。
数据同步
Canal 不仅可以捕获数据变动，还能将这些数据变动同步到其他系统。常见的应用场景包括：
- 同步到搜索引擎： 比如将 MySQL 中的数据变更实时同步到 Elasticsearch，以便提高检索的实时性。
- 同步到数据仓库： 实现 OLAP（联机分析处理）系统中的数据实时同步，比如将数据库变更同步到 Hadoop、ClickHouse 等大数据平台。
- 缓存同步： 数据库变动后，Canal 可以实时更新缓存（如 Redis），以确保缓存中的数据是最新的。
异构数据库支持
Canal 不仅支持 MySQL、PostgreSQL、Oracle 等传统关系型数据库，还支持通过扩展和插件的方式支持更多数据库的接入，适应不同数据库之间的同步需求。
数据解析与转换
Canal 允许对捕获到的数据进行解析和转换。用户可以基于 Canal 提供的 API，定制化处理从数据库中捕获的数据，比如数据格式的转换、过滤等。
Canal 的工作原理
Canal 的工作原理大致分为以下几个步骤：
- 连接数据库：Canal 会连接到源数据库，并获取该数据库的 binlog（对于 MySQL 来说是 binary log，其他数据库有类似机制）。binlog 记录了数据库的所有数据变动操作。
- 解析 binlog：Canal 会持续监听和解析数据库的 binlog 文件。每当有新的数据变动时，Canal 就会读取新的 binlog 并解析出具体的变更内容（插入、更新、删除等）。
- 数据处理：Canal 会将捕获到的变更数据通过数据解析处理，然后根据配置和需求将数据同步到下游系统（例如消息队列、缓存、搜索引擎、数据仓库等）。
- 持久化与监控：Canal 还提供了持久化机制，能够保存已经同步的数据状态，同时具备监控功能，能够及时检测到系统异常并进行告警处理。
Canal 的优势
- 实时性： Canal 可以非常快速地捕获到数据库中的变更，适用于需要实时数据同步的场景。
- 高吞吐量： 它可以处理大量的数据变更，适用于高并发、高吞吐量的场景。
- 灵活性： Canal 提供了丰富的扩展接口和插件支持，用户可以根据自己的需求进行定制化处理。
- 高可用性： Canal 支持分布式部署和高可用架构，可以在多节点之间实现负载均衡和故障切换，保证系统的稳定性。
Canal 的部署与使用
Canal 的部署和使用并不复杂，用户只需配置 Canal 与数据库的连接信息，并定义目标系统，Canal 就能开始实时捕获并同步数据。它支持 单机模式 和 集群模式，用户可以根据实际的吞吐量和可用性需求来选择不同的部署方式。
配置
用户需要配置以下内容：
- 数据库连接信息：包括数据库的 IP、端口、用户名、密码等。
- binlog 配置：指定要监听的 binlog 文件。
- 目标系统配置：配置将变更数据同步到哪个系统，例如 Kafka、Elasticsearch、Redis 等。
启动与监控
Canal 提供了简单的命令行工具来启动服务，并且可以通过 Web 界面或监控系统（如 Prometheus）对 Canal 的运行状态进行实时监控。
使用场景
原始场景
阿里 otter 中间件的一部分 
- 数据同步： 实现不同数据库之间的数据同步，确保数据一致性。
- 实时数据仓库： 将源数据库的变更实时同步到数据仓库中，进行数据分析和报表展示。
- 实时搜索引擎更新： 将数据库的变更实时同步到搜索引擎中，提升搜索的实时性和准确性。
- 缓存更新： 在数据库发生变更时，及时更新缓存中的数据，避免缓存穿透和缓存不一致的问题。
更新缓存
拉链表
订单表，6 月 20 日有 3 条记录： 
到 6 月 21 日，表中有 5 条记录： 
到 6 月 22 日，表中有 6 条记录： 
在数据仓库中设计历史拉链表保存该表 
- dw_begin_date 表示该条记录的生命周期开始时间，dw_end_date 表示该条记录的生命周期结束时间
- dw_end_date = '9999-12-31'表示该条记录属于有效
- 如果查询有效记录则可以直接 where 9999-12-31
- 如果查询 2012-06-21 的历史快照，dw_begin_date <= '2012-06- 21' and end_date >= '2012-06-21'
和原表在 6 月 21 日的记录完全一致，可以看出，这样的历史拉链表，技能满足历史数据的需求，又能很大程度的节省存储空间。
实时统计
抓去业务表的新增变化数据，用于实时统计。
错误速查卡
| 症状 | 根因 | 定位 | 修复 |
|---|---|---|---|
| Canal 无法连接 MySQL | MySQL 未开启 Binlog 或用户权限不足 | 检查 MySQL 配置 show variables like 'log_bin' |
确保 log_bin=ON 并授予 Canal 用户 REPLICATION 权限 |
| 解析的 Data 为空 | 订阅的表没有主键 | 检查表结构 SHOW CREATE TABLE xxx |
为需要 CDC 的表添加主键或唯一索引 |
| 数据延迟过高 | 网络带宽不足或下游系统吞吐低 | 查看 Canal metrics 中的 lag 指标 | 增加 Canal 实例或优化下游消费能力 |
| 重复消费数据 | Client 未正确处理 ACK | 检查 Client 代码的 ACK 逻辑 | 确保每次消费后正确提交 Position |
| Position 丢失 | 未开启 GTID 模式 | 检查 Canal 配置中的 mode | 开启 Canal 的 GTID 或 File+Position 模式 |