前提

这是一篇憋了很久的文章，一直想写，却又一直忘记了写。整篇文章可能会有点流水账，相对详细地介绍怎么写一个小型的"框架"。这个精悍的胶水层已经在生产环境服役超过半年，这里尝试把耦合业务的代码去掉，提炼出一个相对简洁的版本。

之前写的几篇文章里面其中一篇曾经提到过Canal解析MySQL的binlog事件后的对象如下（来源于Canal源码com.alibaba.otter.canal.protocol.FlatMessage）：

如果直接对此原始对象进行解析，那么会出现很多解析模板代码，一旦有改动就会牵一发动全身，这是我们不希望发生的一件事。于是花了一点点时间写了一个Canal胶水层，让接收到的FlatMessage根据表名称直接转换为对应的DTO实例，这样能在一定程度上提升开发效率并且减少模板化代码，这个胶水层的数据流示意图如下：

要编写这样的胶水层主要用到：

• 反射。
• 注解。
• 策略模式。
• IOC容器（可选）。

项目的模块如下：

• canal-glue-core：核心功能。
• spring-boot-starter-canal-glue：适配Spring的IOC容器，添加自动配置。
• canal-glue-example：使用例子和基准测试。

下文会详细分析此胶水层如何实现。

前提

Canal上一个正式版是于2019-9-2发布的v1.1.4，笔者几个月前把这个版本的Canal推上了生产环境，部署了HA集群。过程中虽然遇到不少的坑，但是在不出问题的前提下，Canal的作用还是非常明显的。上周的一次改造上线之后，去掉了原来对业务系统订单数据通过RabbitMQ实时推送的依赖，下游的统计服务完全通过上游业务主库的binlog事件进行聚合，从而实现了核心业务和实时统计两个不同的模块解耦。

这篇文章简单分析一下如何搭建生产环境下可靠的Canal高可用集群。

前提

在忍耐了很久之后，忍不住爆发了，在掘金发了条沸点（下班时发的）：

这是一个令人悲伤的故事，这条情感爆发的沸点好像被屏蔽了，另外小水渠（Canal意为水道、管道）上线一段时间，不出坑的时候风平浪静，一旦出坑令人想屎。重点吐槽几点：

• 目前最新的RELEASE版本为v1.1.4，发布于2019-9-2，快一年没更新了。
• Issue里面堆积了十分多未处理或者没有回应的问题，有不少问题的年纪比较大。
• master分支经常提交异常的代码，构建不友好，因为v1.1.4比较多问题，也曾经想过用master代码手动构建，导入项目之后决定放弃，谁试试谁知道，可以尝试对比导入和构建MyBatis的源码。

这些都只是表象，下面聊聊踩过的坑。

前提

近段时间，业务系统架构基本完备，数据层面的建设比较薄弱，因为笔者目前工作重心在于搭建一个小型的数据平台。优先级比较高的一个任务就是需要近实时同步业务系统的数据（包括保存、更新或者软删除）到一个另一个数据源，持久化之前需要清洗数据并且构建一个相对合理的便于后续业务数据统计、标签系统构建等扩展功能的数据模型。基于当前团队的资源和能力，优先调研了Alibaba开源中间件Canal的使用。

这篇文章简单介绍一下如何快速地搭建一套Canal相关的组件。