乐趣区

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

jiezi

作者：幻好
起源：恒生 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 就是实现数据异构的伎俩之一。

退出移动版