从 Canal 系列的第一篇文章我们基本能了解到，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 的架构图如下图所示：
Canal 中数据的同步是由 CanalInstance 组件负责，一个 Canal Server 实例中可以创建多个 CanalInstance 实例。
每一个 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 Instance 比较简单，只需设置参数，并创建 CanalInstanceWithManger 方法即可，正如示例代码中使用的那样。
另外 Canal 提供了对 Spring 的整合，将 canal Instance 的相关核心组件纳入 Spring 的管理，其实现类为：CanalInstanceWithSpring，对应的 Spring 配置示例如下图所示：
温馨提示：基于 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 的所有一切，都可以从这里窥探出端倪，然后可以选择感兴趣的内容加以继续深入学习。
