作者：幻好
起源：恒生LIGHT云社区

随着零碎业务量的不断扩大，都会应用分布式的形式，同时会有十分多的中间件，如redis、音讯队列、大数据存储等，然而理论外围的数据存储仍然是存储在数据库，多个数据库之前就会存在数据实时同步的问题，为了解决这个问题，须要采纳一些数据实时同步中间件来解决问题。

Canal简介

Canal是阿里开源的一款基于 Mysql数据库 binlog的增量订阅和生产组件，通过它能够订阅数据库的 binlog日志，而后进行一些数据生产，如数据镜像、数据异构、数据索引、缓存更新等。绝对于音讯队列，通过这种机制能够实现数据的有序化和一致性。

设计背景

晚期，阿里巴巴B2B公司因为存在杭州和美国双机房部署，存在跨机房同步的业务需要。不过晚期的数据库同步业务，次要是基于trigger的形式获取增量变更，不过从2010年开始，阿里系公司开始逐渐的尝试基于数据库的日志解析，获取增量变更进行同步，由此衍生出了增量订阅&生产的业务，从此开启了一段新纪元。

目前外部应用的同步，曾经反对mysql5.x和oracle局部版本的日志解析。

基于日志增量订阅&生产反对的业务：

  1. 数据库镜像
  2. 数据库实时备份
  3. 多级索引 (卖家和买家各自分库索引)
  4. search build
  5. 业务cache刷新
  6. 价格变动等重要业务音讯

工作原理

mysql主备复制实现


从下层来看，复制分成三步：

  1. master将扭转记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events，能够通过show binlog events进行查看）；
  2. slave将master的binary log events拷贝到它的中继日志(relay log)；
  3. slave重做中继日志中的事件，将扭转反映它本人的数据。

canal的工作原理

原理绝对比较简单：

  1. canal模仿mysql slave的交互协定，假装本人为mysql slave，向mysql master发送dump协定
  2. mysql master收到dump申请，开始推送binary log给slave(也就是canal)
  3. canal解析binary log对象(原始为byte流)

底层架构

阐明：

  • server代表一个canal运行实例，对应于一个jvm
  • instance对应于一个数据队列 （1个server对应1..n个instance)

instance模块：

  • eventParser (数据源接入，模仿slave协定和master进行交互，协定解析)
  • eventSink (Parser和Store链接器，进行数据过滤，加工，散发的工作)
  • eventStore (数据存储)
  • metaManager (增量订阅&生产信息管理器)

EventParser设计

整个 parser过程大抵可分为几步：

  1. Connection获取上一次解析胜利的地位 (如果第一次启动，则获取初始指定的地位或者是以后数据库的binlog位点)
  2. Connection建设链接，发送BINLOG_DUMP指令
    // 0. write command number
    // 1. write 4 bytes bin-log position to start at
    // 2. write 2 bytes bin-log flags
    // 3. write 4 bytes server id of the slave
    // 4. write bin-log file name
  3. Mysql开始推送Binaly Log
  4. 接管到的Binaly Log的通过Binlog parser进行协定解析，补充一些特定信息
    // 补充字段名字，字段类型，主键信息，unsigned类型解决
  5. 传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储胜利
  6. 存储胜利后，定时记录Binaly Log地位

EventSink设计

阐明：

  • 数据过滤：反对通配符的过滤模式，表名，字段内容等
  • 数据路由/散发：解决1:n (1个parser对应多个store的模式)
  • 数据归并：解决n:1 (多个parser对应1个store)
  • 数据加工：在进入store之前进行额定的解决，比方join

EventStore设计

  • 1.目前仅实现了Memory内存模式，后续打算减少本地file存储，mixed混合模式
  • 2.借鉴了Disruptor的RingBuffer的实现思路

RingBuffer设计：

定义了3个cursor

  • Put : Sink模块进行数据存储的最初一次写入地位
  • Get : 数据订阅获取的最初一次提取地位
  • Ack : 数据生产胜利的最初一次生产地位

Instance设计

instance代表了一个理论运行的数据队列，包含了 EventPaser,EventSink,EventStore等组件。

形象了 CanalInstanceGenerator，次要是思考配置的治理形式：

  • manager形式： 和你本人的外部web console/manager零碎进行对接。(目前次要是公司外部应用)
  • spring形式：基于spring xml + properties进行定义，构建spring配置。

Server设计

server代表了一个canal的运行实例，为了不便组件化应用，特意形象了 Embeded(嵌入式) / Netty(网络拜访)的两种实现

  • Embeded : 对latency和可用性都有比拟高的要求，本人又能hold住分布式的相干技术(比方failover)
  • Netty : 基于netty封装了一层网络协议，由canal server保障其可用性，采纳的pull模型，当然latency会略微打点折扣，不过这个也视状况而定。(阿里系的notify和metaq，典型的push/pull模型，目前也逐渐的在向pull模型聚拢，push在数据量大的时候会有一些问题)

HA机制

canal的 ha分为两局部，canal server和 canal client别离有对应的ha实现

  • canal server: 为了缩小对mysql dump的申请，不同server上的instance要求同一时间只能有一个处于running，其余的处于standby状态.
  • canal client: 为了保障有序性，一份instance同一时间只能由一个canal client进行get/ack/rollback操作，否则客户端接管无奈保障有序。

整个HA机制的管制次要是依赖了 zookeeper的几个个性，watcher和 EPHEMERAL节点(和 session生命周期绑定)。

Canal Server:

大抵步骤：

  1. canal server要启动某个canal instance时都先向zookeeper进行一次尝试启动判断 (实现：创立EPHEMERAL节点，谁创立胜利就容许谁启动)
  2. 创立zookeeper节点胜利后，对应的canal server就启动对应的canal instance，没有创立胜利的canal instance就会处于standby状态
  3. 一旦zookeeper发现canal server A创立的节点隐没后，立刻告诉其余的canal server再次进行步骤1的操作，从新选出一个canal server启动instance.
  4. canal client每次进行connect时，会首先向zookeeper询问以后是谁启动了canal instance，而后和其建设链接，一旦链接不可用，会从新尝试connect.

Canal Client的形式和 canal server形式相似，也是利用 zookeeper的抢占EPHEMERAL节点的形式进行管制。

利用场景

数据同步

  • 微服务开发环境下，为了进步搜寻效率，以及搜寻的精准度，会大量应用Redis、Mongodb等NoSQL数据库，也会应用大量的Solr、Elasticsearch等全文检索服务。那么，这个时候，就会有一个问题须要咱们来思考和解决：那就是数据同步的问题！
  • Canal能够将实时变动的数据库中的数据同步到Redis,Mongodb或者Solr/Elasticsearch中。

数据异构

在大型网站架构中，DB都会采纳分库分表来解决容量和性能问题，但分库分表之后带来的新问题。比方不同维度的查问或者聚合查问，此时就会十分辣手。个别咱们会通过数据异构机制来解决此问题，数据异构就是将须要join查问的多表依照某一个维度又聚合在一个DB中。让你去查问。canal就是实现数据异构的伎俩之一。