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

[](http://creativecommons.org/licenses/by-sa/4.0/)版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文链接：https://blog.csdn.net/github_37947909/article/details/87183009

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

起因：

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

  • 对于简单的跨库join操作，使用服务层代码进行数据组装的方式，通过服务调用 + 数据库in查询的方式解决。
  • 对于复杂的业务操作，使用数据异构同步的方式，将细化后的商品信息同步、聚合到依赖模块的库中，以满足复杂业务的需求。

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

技术清单：

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

架构设计图：基于alibaba-canal的异构数据同步解决方案

组件分析：

canal:

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

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

canal工作原理

zookeeper：

​ canal高可用依赖。

HA机制

binlog-subscribe:

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

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

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

MQ:

​ 主要用于解耦。

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

下游服务：

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

Original url: Access
Created at: 2019-09-09 15:15:32
Category: default
Tags: none

未标明原创文章均为采集，版权归作者所有，转载无需和我联系，请注明原出处，南摩阿彌陀佛，知识，不只知道，要得到

请先后发表评论
  • 最新评论
  • 总共0条评论