基于alibaba-canal的异构数据同步解决方案

随着业务的发展，公司的整体架构方向向微服务演进。随之衍生出各种问题，本文主要提供的是数据库隔离（分库）之后的跨库join问题一种解决方案。

起因：

​ 商品服务的抽离，表结构细化；导致各依赖模块出现了各种跨库join问题。在某些复杂的业务场景下，基于原表（未分库前的商品信息）的一次join操作，在新的表结构下需要做多次跨库join。基于此场景，最终确定了技术方案：

• 对于简单的跨库join操作，使用服务层代码进行数据组装的方式，通过服务调用 + 数据库in查询的方式解决。

• 对于复杂的业务操作，使用数据异构同步的方式，将细化后的商品信息同步、聚合到依赖模块的库中，以满足复杂业务的需求。

  本文主要介绍一种基于alibaba-canal的数据异构同步的解决方案。

技术清单：

• Mysql – 数据库
• Canal– alibaba开源的数据库日志监听中间件
• Zookeeper – canal高可用的依赖
• RocketMQ – 消息服务

架构设计图：

组件分析：

canal:

​ 最初有考虑在商品服务中埋点，使用事件监听的模型来做这个同步需求（即每次数据库的增删改都会触发同步事件）。

​ 后期分析认为，数据异构同步应采用一种脱离于业务需求之外的，不能对业务有入侵的一种方案来进行。而数据的改动最终都将落实到数据库层面，于是最终采用了基于canal的，监听源库日志的同步方式。

zookeeper：

​ canal高可用依赖。

binlog-subscribe:

​ binlog-subscribe用于监听canal分析后的binlog日志，经过二次筛选，解耦，将需要关注的数据库变更信息分装并发送到MQ组件。

​ **client订阅过滤：**由于canal自带的filter不能过滤到column级别，所以在本架构中，索性只负责更粗粒度的筛选-schemas；而对于不同的下游消费系统，需要关注的具体的表和字段不同，将这些下游消费系统需要关注的具体字段/表的交集写入配置，配置成二次筛选的条件。

​ **字段映射解耦：**根据配置，将源库的字段名与MQ消息中的实体字段名做一层映射解耦，下游系统依赖MQ消息实体中的字段名，而不依赖源表column，避免源表字段更新对下游系统造成影响。

MQ:

​ 主要用于解耦。

​ 将过滤、封装后的数据库变更信息写入MQ，下游服务自行订阅消费。

下游服务：

​ 订阅MQ消息，处理，聚合数据。