zoukankan      html  css  js  c++  java
  • 【Canal源码分析】整体架构

    本文详解canal的整体架构。

    一、整体架构

    canal架构图.png

    canal架构图2.png

    说明:

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

    instance模块:

    • eventParser (数据源接入,模拟slave协议和master进行交互,协议解析)
    • eventSink (Parser和Store链接器,进行数据过滤,加工,分发的工作)
    • eventStore (数据存储)
    • metaManager (增量订阅&消费信息管理器)

    二、各模块架构

    2.1 Parser

    EventParser架构.png

    整个parser过程大致可分为几步:

    • Connection获取上一次解析成功的位置(如果第一次启动,则获取初始制定的位置或者是当前数据库的binlog位点)
    • Connection建立连接,发生BINLOG_DUMP命令
    • Mysql开始推送Binary Log
    • 接收到的Binary Log通过Binlog parser进行协议解析,补充一些特定信息
    • 传递给EventSink模块进行数据存储,是一个阻塞操作,直到存储成功
    • 存储成功后,定时记录Binary Log位置

    2.2 Sink

    Sink.png

    说明:

    • 数据过滤:支持通配符的过滤模式,表名,字段内容等
    • 数据路由/分发:解决1:n (1个parser对应多个store的模式)
    • 数据归并:解决n:1 (多个parser对应1个store)
    • 数据加工:在进入store之前进行额外的处理,比如join

    1 数据1:n业务 :

    为了合理的利用数据库资源, 一般常见的业务都是按照schema进行隔离,然后在mysql上层或者dao这一层面上,进行一个数据源路由,屏蔽数据库物理位置对开发的影响,阿里系主要是通过cobar/tddl来解决数据源路由问题。 所以,一般一个数据库实例上,会部署多个schema,每个schema会有由1个或者多个业务方关注。

    2 数据n:1业务:

    同样,当一个业务的数据规模达到一定的量级后,必然会涉及到水平拆分和垂直拆分的问题,针对这些拆分的数据需要处理时,就需要链接多个store进行处理,消费的位点就会变成多份,而且数据消费的进度无法得到尽可能有序的保证。 所以,在一定业务场景下,需要将拆分后的增量数据进行归并处理,比如按照时间戳/全局id进行排序归并.

    2.3 Store

    目前实现了Memory内存、本地file存储以及持久化到zookeeper以保障数据集群共享。
    Memory内存的RingBuffer设计:

    store ringBuffer.png

    定义了3个cursor

    • Put : Sink模块进行数据存储的最后一次写入位置
    • Get : 数据订阅获取的最后一次提取位置
    • Ack : 数据消费成功的最后一次消费位置

    借鉴Disruptor的RingBuffer的实现,将RingBuffer拉直来看:

    store ringBuffer2.png

    实现说明:

    Put/Get/Ack cursor用于递增,采用long型存储
    buffer的get操作,通过取余或者与操作。(与操作: cusor & (size – 1) , size需要为2的指数,效率比较高)

  • 相关阅读:
    smbmnt
    smbd
    smbcontrol
    smbclient
    smb.conf
    sleep
    size
    oracle-rman-1
    cURL 学习笔记与总结(5)用 cURL 访问 HTTPS 资源
    Java实现 LeetCode 90 子集 II(二)
  • 原文地址:https://www.cnblogs.com/f-zhao/p/9112158.html
Copyright © 2011-2022 走看看