时间复杂度与空间复杂度，你了解多少

Canal 就是模拟了这个过程。

Canal模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送 dump 协议;

MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal );

Canal 解析 binary log 对象(原始为 byte 流);
 

对于引擎层，最核心的在于技术选型。需要结合业务需求、开源项目稳定性、开源项目功能特点综合分析，下文我们会仔细展开说明。

另外，对于生产环境使用的项目，必须做好配套的监控告警措施，保证线上的稳定性。

otter/canal都有现成的监控指标，我们需要将 同步延迟 等关键指标进行采集，并设置合理的告警阈值。

同时，对于一些没有现成的监控指标，比如 任务存活状态 等，我们可以通过 巡检 进行定时检查，避免由于同步任务挂起而影响上层业务。

4.数据订阅模块

4.1 技术选型

数据订阅实际上就是一种CDC(Change Data Capture)工具，目前开源产品中比较成熟的有Canal、DataX、DataBus、Debezium等。

整体而言，Canal、DataX、Debezium的使用人数多，社区活跃，框架也比较成熟。在满足应用场景的前提下，优先选择，代价适中。

DataX支持丰富，使用简单，但延迟较大(依赖获取频率)，只需要手写规则文件，对复杂同步自定义性不强。

Debezium虽然比Canal支持更多类型的数据源，但是我们实际上只需要mysql，并不需要PostgreSQL这些的支持。

而Canal有几点特性我们非常需要，让我们决定使用Canal作为数据订阅引擎：

• 对阿里云RDS有特殊定制优化，可以自动下载备份到oss的binlog文件然后指定位点开始同步
• 有非常友好的控制台
• 支持投递到Rocketmq
• 新版本的Canal-Adapter可以支持多种客户端消费，包括mysql、es等

4.2 基本原理

数据订阅的原理基本一样，都是基于MySQL的主从复制原理实现。

MySQL的主从复制分成三步：

• master将改变记录到二进制日志(binary log)中(这些记录叫做二进制日志事件，binary log events，可以通过show binlog events进行查看);
• slave将master的binary log events拷贝到它的中继日志(relay log);
• slave重做中继日志中的事件，将改变反映它自己的数据。