乐趣区

关于数据库:认识数据实时同步神器Canal~

作者:幻好
起源:恒生 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. slavemasterbinary log events拷贝到它的中继日志(relay log);
  3. slave重做中继日志中的事件,将扭转反映它本人的数据。

canal 的工作原理

原理绝对比较简单:

  1. canal模仿 mysql slave 的交互协定,假装本人为 mysql slave,向mysql master 发送 dump 协定
  2. mysql master收到 dump 申请,开始推送 binary logslave(也就是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. 借鉴了 DisruptorRingBuffer的实现思路

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 会略微打点折扣,不过这个也视状况而定。(阿里系的 notifymetaq,典型的 push/pull 模型,目前也逐渐的在向 pull 模型聚拢,push在数据量大的时候会有一些问题)

HA 机制

canalha分为两局部,canal servercanal client别离有对应的 ha 实现

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

整个 HA 机制的管制次要是依赖了 zookeeper的几个个性,watcherEPHEMERAL节点 (和 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 节点的形式进行管制。

利用场景

数据同步

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

数据异构

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

退出移动版