Instance 是 Canal 数据同步的核心，在一个 Canal 实例中只有启动 Instace，才能实现数据的同步，那 Instance 到底是“何许人也”，以源码为手段，试图揭开 Instance 的神秘面纱。

1、Canal Instance 类继承体系

 

• CanalInstanceCanal Instance 接口，即定义 Instance 的基本特征，主要定义如下方法：

• String getDestination()
  实例的目的地名称，在 Canal 中表示一个源实例名称，对应一个 MySQL 实例信息，例如 192.168.1.3:3306，这里为该实例取一个名称。

• CanalEventParser getEventParser()
  事件解析器，即 Binlog 解析器，负责解析 binlog 日志。

• CanalEventSink getEventSink()
  EventParse 与 EventStore 的连接器，主要处理数据的过滤、加工与分发，即提供了对 binlog 原始数据进行“加工”的切入点，EventStore 存储的就是经 EventSink处理过的数据。

• CanalEventStore getEventStore()
  事件存储器，即 Canal Instance 作为 MySQL 的 "Slave" 服务器，需要将同步过来的数据进行存储，然后被 Canal 的客户端最终会从 EventStore 中获取数据，目前 Canal 只实现了基于内存的 EventStore，那 Canal 是如何避免内存泄露，并且如何避免数据丢失的，这将是后续我们需要研究的重点。

• CanalMetaManager getMetaManager()
  Canal 元数据管理器，例如记录 消费端消费进度，即从 Canal EventStore 中处理数据的情况。

• CanalAlarmHandler getAlarmHandler()
  告警服务。

• AbstractCanalInstance
  CanalInstance的抽象实现类。

• CanalInstanceWithManager
  基于手动编程式的 CanaInstance，主要通过API的方式手动生成 CanalInstance 实例。可以类比 Spring 基于编程API 的事务管理器。

• CanalInstanceWithSpring
  基于 Spring 方式构建 CanaInstance。

• CanalInstanceGenerator
  Canal Instance 的构造类体系，即通过该类提供的方法创建 CanalInstance 实例，提供基于 Spring、手动管理等方式。

2、CanalInstance 四大核心组件

从类层次了解 Canal Instance 显得不那么直观，接下来先抛出一个使用场景，再结合架构图进一步加深对 Canal Instance 的理解。

例如某公司的订单系统使用了分库分表，数据库的分别部署在 192.168.1.166:3306，192.168.1.168:3306 两个数据库，并且每一个数据库上会创建多个 schema，例如 order_db、user_db，那现在为了对订单提供多维度的查询，统计等功能，架构组因此提出通过订阅数据库 binlog 日志，将两个订单库中的订单数据，即将 order_db 中的数据同步到 elasticsearch，而 Canal 的设计初衷就是为了解决上述问题，故我们可以边思考这个场景，来反推一下 Canal Instance 的设计理念。

Canal Instance 的架构图如下图所示：

 

每一个 CanalInstance 可以看成是对应一个 MySQL 实例，即案例中需要同步两个数据库实例，故最终需要创建两个 CanalInstance。其实也不难理解，因为 MySQL 的 binlog 就是以实例为维度进行存储的。Canal Instance 包含了 4个 核心组件 ：EventParse、EventSink、EventStore、CanaMetaManager，在这里主要是阐明其作用，后续文章会一一详细介绍，以便更好的指导实践。

• EventParse 组件
  负责解析 binlog日志，其职责就是根据 binlog 的存储格式将有效数据提取出来，这个不难理解，我们也可以通过该模块，进一步了解一下 binglog 的存储格式。

• EventSink 组件
  结合数据同步案例，在一个数据库实例上通常会创建多个 Schema，但通常并不是所有的 schema 都需要被同步，如果直接将 EventParse 解析出来的数据全部传入EventStore 组件，将对 EventStore 带来不必要的性能消耗；另外本例中使用了分库分表，需要将多个库的数据同步到单一源，可能需要涉及到合并、归并等策略。以上等等等需求就是 EventSink 需要解决的问题域。

• EventStore 组件
  用来存储经 canal 转换的数据，被 Canal Client 进行消费的数据，目前 Canal 只提供了基于内存的存储实现。大家不妨先思考一下，采用基于内存的存储模式，如何避免内存溢出，其具体实现将在后续文章中详细剖析。

• CanalMetaManager 组件
  元数据存储管理器。在 Canal 中最基本的元数据至少应该包含 EventParse 组件解析的位点与消费端的消费位点。Canal Server 重启后要能从上一次未同步位置开始同步，否则会丢失数据。在将数据库数据同步到 es 的示例中，所谓的 canal 客户端就是从 Canal Server 即 EventStore 中获取数据，并将数据写入 es 中，并上报写入进度，这些信息都是由 CanalMetaManager 组件完成。

从最新的版本来看，Canal 支持直接将解析后的数据发送到MQ，故 CanalInstance 中还持有另外一个组件：CanalMQConfig，关于 MQ 的一些配置，提供了多种策略实现 shcema、table 到 MQ Topic 的自动映射管理，为 Canal 的使用者带来更多便利，这部分内容会在后续文章中单独介绍，这里先暂时不过多讨论。

经过上面的了解，我想大家对 Canal Instance 有了一个相对全面的了解了吧，接下来我们再来关注一下 CanalInstance 的构造方式，这个对后续的实践有着非常重要的影响。

3、CanalInstance 构造方式

Canal 中提供了两种方式对 Instance 进行初始化：Spring 与 手动编程方式。CanalInstance 最最核心的就是上述提到的4个组件，即 CanalInstanceWithManager 类的具体职责就是管理上述核心组件，即提供对上述组件的加载、启动、停止，并协调，从其名字就能看出来，从其构造函数同样能得知：

 

 

温馨提示：基于 Canal 二次开发的编程技巧思考如下：Canal 框架本身将 Canal Server 做成了启动脚本，可以通过自定义 Instance，即从 instance 配置文件中加载配置，然后启动 Canal Server 解析 Binlog 日志，最终按照预定的配置进行工作，例如在生产环境搭建一些 Canal 集群，统一交由运维去手动维护，如果需要数据同步，则配置相应的 instance 文件，然后进行启动就生效，其实这种模式处于 Canal 的初阶阶段，更好的方式是对 Canal 进行二次开发，通过可视化的界面，通过界面的方式定义数据同步任务，例如将指定数据库实例上的指定 Schema 的 binglog 日志同步到指定消息集群的指定 topic，并且可重推、随时停止，重启，这样 Canal 的维护者无需关注底层的细节，只需要通过页面简单配置一下即可。

源码 Canal 系列的第一篇文章后有好几个粉丝表示目前也在研究 Canal，由于笔者目前只能尽量保持周更，如果大家希望加快研究 Canal 的步伐，笔者有如下建议：

1、深入研究其四大核心组件，并带着问题去研究，例如在学习元数据管理时是如何保证数据不丢失，重启后又是如何定位位点的。

2、如果大家想更全局的去研究 Canal，我觉得除了阅读 Canal 官方的设计手册，还可以专门去看一下 CanalParameter 这个类，Canal 支持的所有配置属性，并且都有相应的注释，关于 Canal 的所有一切，都可以从这里窥探出端倪，然后可以选择感兴趣的内容加以继续深入学习。