前面的文章使用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

Connection获取上一次解析成功的位置 (如果第一次启动，则获取初始指定的位置或者是当前数据库的binlog位点)

Connection建立链接，发送BINLOG_DUMP指令

Mysql开始推送Binaly Log

接收到的Binaly Log的通过Binlog parser进行协议解析，补充一些特定信息

传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功

存储成功后，定时记录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)

对应的两个位点组件，目前都有几种实现：memorymemory-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:

canal server要启动某个canal instance时都先向zookeeper进行一次尝试启动判断 (实现：创建EPHEMERAL节点，谁创建成功就允许谁启动)

创建zookeeper节点成功后，对应的canal server就启动对应的canal instance，没有创建成功的canal instance就会处于standby状态

一旦zookeeper发现canal server A创建的节点消失后，立即通知其他的canal server再次进行步骤1的操作，重新选出一个canal server启动instance.

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源

对于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

获取数据的方式：达到一定数量或时间