后面的文章应用canal订阅mysql数据变动进而同步数据，这里钻研canal的外部个性，进而更好地应用canal，大部分内容来自官网，还有一部分来自我的了解。
canal主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和生产。

利用场景：

  • 异构数据同步
  • 数据库实时备份
  • 业务cache刷新

原理

canal模仿成mysql slave向master发送dump申请，收到binlog数据进行解析

slave同步master原理：

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

架构


server代表一个canal运行实例，对应于一个jvm
instance对应一个数据队列，一个destination，相当于一个数据库实例变更的监听，1个server对应1-n个instance
instance模块：

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

  1. Connection获取上一次解析胜利的地位 (如果第一次启动，则获取初始指定的地位或者是以后数据库的binlog位点)
  2. Connection建设链接，发送BINLOG_DUMP指令
  3. Mysql开始推送Binaly Log
  4. 接管到的Binaly Log的通过Binlog parser进行协定解析，补充一些特定信息
  5. 传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储胜利
  6. 存储胜利后，定时记录Binaly Log地位
EventSink

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

Instance设计


instance代表了一个理论运行的数据队列，包含了EventPaser,EventSink,EventStore等组件。形象了CanalInstanceGenerator，次要是思考配置的治理形式：

  • manager形式：提供http形式，能够和公司外部web console/manager零碎进行对接。
  • spring形式：基于spring xml + properties进行定义，通过spring配置

Spring配置

spring配置的原理是将整个配置形象为两局部：

  • xxxx-instance.xml (canal组件的配置定义，能够在多个instance配置中共享，在canal.properties中配置)
  • xxxx.properties (每个instance通道都有各自一份定义，因为每个mysql的ip，帐号，明码等信息不会雷同)

通过spring的PropertyPlaceholderConfigurer通过机制将其交融，生成一份instance实例对象，每个instance对应的组件都是互相独立的，互不影响

properties配置文件

properties配置分为两局部：

  • canal.properties (零碎根配置文件，配置destinations，注册IP，启动端口)
  • instance.properties (instance级别的配置文件，每个instance一份，配置数据库信息，监听的表)

canal.properties介绍：
canal配置次要分为两局部定义：

  • instance列表定义 (列出以后server上有多少个instance，每个instance的加载形式是spring/manager等)
  • common参数定义，比方能够将instance.properties的专用参数，抽取搁置到这里，这样每个instance启动的时候就能够共享. 【instance.properties配置定义优先级高于canal.properties】
canal如何保护一份增量订阅&生产的关系信息：
  • 解析位点 (parse模块会记录，上一次解析binlog到了什么地位，对应组件为：CanalLogPositionManager)
  • 生产位点 (canal server在接管了客户端的ack后，就会记录客户端提交的最初位点，对应的组件为：CanalMetaManager)

对应的两个位点组件，目前都有几种实现：

  • memory

    • memory-instance.xml中应用，所有的组件(parser , sink , store)都抉择了内存版模式，记录位点的都抉择了memory模式，重启后又会回到初始位点进行解析
    • 速度最快，依赖起码(不须要zookeeper)
    • 场景：个别利用在quickstart，或者是呈现问题后，进行数据分析的场景，不应该将其利用于生产环境
  • zookeeper
  • mixed

  • period：

    • default-instance.xml中应用，汇合了zookeeper+memory模式，store抉择了内存模式，其余的parser/sink依赖的位点治理抉择了长久化模式，目前长久化的形式次要是写入zookeeper，保证数据集群共享
    • 反对HA，可用于生产环境，集群化部署

一份 instance.xml 中有一份或者多份 instance 定义，优先以 destination 名字查找对应的 instance bean 定义，如果没有，则按默认的名字 “instance” 查找 instance 对象,例如 xxxx-instance.xml 中定义 id 别离为 instance-1, instance-2 的两个 bean. 这两个 bean 将为同名的 instance 提供自定义的 eventParser , evnetSink , evnetStore , metaManager，alarmHandler.如果没有自定义这些 bean, 就应用 id="instance" 的 bean 来配置 canal instance.
一份 instance bean 定义，须要蕴含 eventParser , evnetSink , evnetStore , metaManager，alarmHandler 的5个模块定义，( alarmHandler 次要是一些报警机制解决，因为简略没开展，可扩大)
instance.xml设计初衷：
容许进行自定义扩大，比方实现了基于数据库的位点治理后，能够自定义一份本人的instance.xml，整个canal设计中最大的灵活性在于此

HA模式配置

canal的ha分为两局部：

  • canal server: 不同server上的instance要求同一时间只能有一个处于running，其余的处于standby状态，不然就是对mysql dump的反复申请。这里是instance/destination级别的负载平衡，而不是server
  • 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节点的形式进行管制.

canal失落数据的状况：

失常状况下，在canal server/client挂掉或切换的状况下不会失落数据，因为zk会长久化server解析binlog及clinet生产数据的地位，重启时会从新读取。以下状况可能会失落数据：

  • zk保留的元数据被人为批改，如server解析binlog及clinet生产数据的地位
  • client应用get办法而非getWithoutAck，如果client生产数据时挂掉，server会认为这部分数据曾经被生产而失落
  • MySQL binlog非正常运维，比方binglog迁徙、重命名、失落等
  • 切换MySQL源，比方原来基于M1实例，起初M1因为某种原因生效，那么Canal将数据源切换为M2，而且M1和M2可能binlog数据存在不统一

Canal性能剖析

  • canal解决数据流程为master-parse-sink-store-comsume，整个流程中都是单线程、串行、阻塞式的。如果批量insert、update、delete，都可能导致大量的binlog产生，也会加剧Master与slave之间数据同步的提早。（写入频繁）。
  • 如果client生产的效力较低，比方每条event执行耗时很长。这会导致数据变更的音讯ACK较慢，那么对于Canal而言也将阻塞sotre，没有有足够的空间存储新音讯进而梗塞parse解析binlog。
  • Canal自身十分轻量级，次要性能开销就是在binlog解析，其转发、存储、提供消费者服务等都很简略。它自身不负责数据存储。原则上，canal解析效率简直没有负载，canal的自身的提早，取决于其与slave之间的网络IO。

Canal导致反复生产

  • Canal instance初始化时，依据“消费者的Cursor”来确定binlog的起始地位，然而Cursor在ZK中的保留是滞后的（间歇性刷新），所以Canal instance取得的起始position肯定不会大于消费者实在已见的position。
  • Consumer端，因为某种原因的rollback，也可能导致一个batch内的所有音讯重发，此时可能导致反复生产。

因而Consumer端须要放弃幂等，对于反复数据能够进行校验或者replace。对于非幂等操作，比方累加、计费，须要谨慎。

destination的生产问题

一个destination无奈被多个client间接并行生产，解决方案：

  • client收到音讯当前转发到kafka或者MQ中，后继的其余Consumer只与kafka或者MQ接入
  • 一个Canal中应用多个destination，它们对应雷同的MySQL源

参考：
https://github.com/alibaba/canal/wiki/AdminGuide
https://www.bookstack.cn/read/canal-v1.1.4/10a3a22ce51cd92e.md
https://blog.csdn.net/guanfengliang1988/article/details/107357853

对于canal设计的一些思考

  • 对于canal的高可用，通过zk保障server和client同一时间只能有一个节点工作

    • server能不能依据数据id进行分片读取，进步读取数据的性能，相似kafka的设计，应该是不能的。因为parser向master发动dump申请失去的是字节流，无奈获取原始数据。那能不能一个parser对应多个sink再放入store。没必要，因为canal的性能瓶颈在canal与数据库的网络IO，解析及sink是很快的。
    • 客户端能不能多个节点同时工作，从一个destination生产数据。如果不保证数据胜利生产及有序性是能够的。如果某一client生产数据失败，以后store的设计（环形构造保留数据）无奈做到回滚。如果一个destination分多个队列由client生产，只能保证数据部分有序，同时设计简单。

  • 以后store的数据保留在内存中，是否有必要长久化到文件

    • 相似于logstash的数据也是保留在内存中，官网文档说会反对，但没有也能够，因为长久化会影响整体性能，通过zk存储client的生产地位会保证数据至多被生产一次。
  • store保留的数据受到大小和条数的限度，当达到限度时，sink会梗塞parser，不会撑爆内存
  • canal与logstahs，kafka的一些比拟

对当前写公共组件的一些启发：

  • 反对多种配置形式如配置文件，http，并可动静失效
  • 通过协调服务保证系统的高可用
  • 裸露服务监控指标至prometheus
  • 获取数据的形式：达到肯定数量或工夫