Canal Instance 设计理念与定制开发思路是什么

本文将详细阐述运河实例的设计理念和定制开发思路。文章内容质量很高，我就分享给大家作为参考。希望大家看完这篇文章后对相关知识有一定的了解。

实例是运河数据同步的核心。在Canal实例中，数据同步只能通过启动Instance来实现。那么，instance就是“是谁”，并以源代码为手段，试图揭开Instance的神秘面纱。

1、Canal Instance 类继承体系

重要的类描述如下：

canastancecanalnstance接口定义了Instance的基本特性，主要定义了以下方法：

字符串getDestination()

实例的目标名称，代表了Canal中的一个源实例名称，对应于一个MySQL实例信息，比如192 . 168 . 1 . 33606 . 33603600366这里，为实例取一个名称。

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

基于手动编程的caninstance，通过API手动生成caninstance实例。可以和Spring基于编程API的事务管理器进行对比。

CanalInstanceWithSpring

基于Spring构建CanaInstance。

CanalInstanceGenerator

canalininstance的构造类系统是通过这个类提供的方法创建canalininstance实例，并提供基于spring和手工管理等方式。

00-1010从类的层面理解Canalnstance就没那么直观了。接下来，先抛出一个使用场景，再结合架构图进一步加深对Canalnstance的理解。

例如，一家公司的订单系统使用子数据库和子表，数据库分别部署在两个数据库192.168.1.166:3306和192.168.1.168:3306中，并在每个数据库上创建多个模式，如order_db和user_db。现在，为了提供订单的多维查询。因此，该架构提出通过订阅数据库的binlog日志，将两个订单库中的订单数据，即order_db中的数据同步到elasticsearch。Canal最初是为了解决上述问题而设计的，所以我们可以通过思考这个场景来反转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 的所有一切，都可以从这里窥探出端倪，然后可以选择感兴趣的内容加以继续深入学习。

关于Canal Instance 设计理念与定制开发思路是什么就分享到这里了，希望