Canal——数据同步

1.数据同步到数据库:

  • 在介绍方案2之前我们先来介绍一下MySQL复制的原理,如下图所示:
    • 主服务器操作数据,并将数据写入Bin log
    • 从服务器调用I/O线程读取主服务器的Bin log,并且写入到自己的Relay log中,再调用SQL线程从Relay log中解析数据,从而同步到自己的数据库中

  • 方案2就是:
    • 上面MySQL的整个复制流程可以总结为一句话,那就是:从服务器读取主服务器Bin log中的数据,从而同步到自己的数据库中
    • 我们方案2也是如此,就是在概念上把主服务器改为MySQL,把从服务器改为Redis而已(如下图所示),当MySQL中有数据写入时,我们就解析MySQL的Bin log,然后将解析出来的数据写入到Redis中,从而达到同步的效果

  • 例如下面是一个云数据库实例分析:
    • 云数据库与本地数据库是主从关系。云数据库作为主数据库主要提供写,本地数据库作为从数据库从主数据库中读取数据
    • 本地数据库读取到数据之后,解析Bin log,然后将数据写入写入同步到Redis中,然后客户端从Redis读数据

  • 这个技术方案的难点就在于: 如何解析MySQL的Bin Log。但是这需要对binlog文件以及MySQL有非常深入的理解,同时由于binlog存在Statement/Row/Mixedlevel多种形式,分析binlog实现同步的工作量是非常大的

Canal开源技术

  • canal是阿里巴巴旗下的一款开源项目,纯Java开发。基于数据库增量日志解析,提供增量数据订阅&消费,目前主要支持了MySQL(也支持mariaDB)
  • 开源参考地址有:https://github.com/liukelin/canal_mysql_nosql_sync
  • 工作原理(模仿MySQL复制):
    • canal模拟mysql slave的交互协议,伪装自己为mysql slave,向mysql master发送dump协议
    • mysql master收到dump请求,开始推送binary log给slave(也就是canal)
    • canal解析binary log对象(原始为byte流)

  • 架构:
    • eventParser (数据源接入,模拟slave协议和master进行交互,协议解析)
    • eventSink (Parser和Store链接器,进行数据过滤,加工,分发的工作)
    • eventStore (数据存储)
    • metaManager (增量订阅&消费信息管理器)
    • server代表一个canal运行实例,对应于一个jvm
    • instance对应于一个数据队列 (1个server对应1..n个instance)
    • instance模块:

  • 大致的解析过程如下:
    • parse解析MySQL的Bin log,然后将数据放入到sink中
    • sink对数据进行过滤,加工,分发
    • store从sink中读取解析好的数据存储起来
    • 然后自己用设计代码将store中的数据同步写入Redis中就可以了
    • 其中parse/sink是框架封装好的,我们做的是store的数据读取那一步

  • 更多关于Cancl可以百度搜索
  • 下面是运行拓扑图

  • MySQL表的同步,采用责任链模式,每张表对应一个Filter 。例如zvsync中要用到的类设计如下:

  • 下面是具体化的zvsync中要用到的类 ,每当新增或者删除表时,直接进行增删就可以了

Canal的架构设计

Canal 伪装成 MySQL 从节点,mySQL master 会推送 binary log 给canal,canal读取 MySQL binlog的变更信息并生成消息,客户端订阅这些数据变更消息,处理并存储。只要开发一个 Canal客户端就可以解析出MySQL的操作,再将这些数据发送到大数据流计算处理引擎,即可以实现对 MySQL 实时处理。

我们一般使用canal时,只需要引入一个客户端,比如java类似这样:

<dependency>

<groupId>com.alibaba.otter</groupId>

<artifactId>canal.client</artifactId>

<version>1.1.0</version>

</dependency>

然后就可以订阅binlog消息了。

另外canal也支持直接把binlog消息发送到mq,这样对多语言的支持更好一些。

canal自身帮我们做了很多事,这样我们自己写的客户端才能更简单,更专注于业务。下面就来看看canal内部的架构。

说明:

server代表一个canal运行实例,对应于一个jvm

instance对应于一个数据队列

核心是instance模块,它包含:

  1. eventParser (数据源接入,模拟slave协议和master进行交互,协议解析)

parser模块

parser模块用来订阅binlog事件,然后通过sink投递到store。parser模块底层依赖dbsync、driver模块。

eventSink (Parser和Store链接器,进行数据过滤,加工,分发的工作)

  1. eventStore (数据存储)

  1. metaManager (增量订阅&消费信息管理器)

meta模块

核心接口为CanalMetaManager,实现了订阅&消费的机制,主要用于记录canal消费到的mysql binlog的位置。CanalMetaManager接口有几个实现类:

FileMixedMetaManager

MemoryMetaManager

MixedMetaManager

PeriodMixedMetaManager

ZooKeeperMetaManager

这些实现类之间有些会持有其它实现的引用来装饰自己的功能(装饰器模式),

CanalServer的两种实现方式

这两个实现代表了canal的两种应用模式,CanalServerWithNetty在canal独立部署场景发挥作用,开发者只需要实现cient,不同的应用通过canal client与canal server进行通信,canal client的请求统一由CanalServerWithNetty接受进行处理。

而通过CanalServerWithEmbeded,可以不需要独立部署canal,而是把canal嵌入到我们自己的服务里。但是这种对开发者的要求就比较高。

下面的图表示二者的关系,

CanalServerWithEmbedded 内部管理所有的CanalInstance,通过 Client 的信息(destination),找到 Client 订阅的 CanalInstance,然后调用 CanalInstance 内部的各个模块进行处理(4个模块 )

CanalInstance模块解析

  • 3
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值