canal
简介
canal是java开发的基于数据库日志解析,提供增量数据订阅&消费的中间件.目前,canal主要支持了mysql的binlog解析,解析完成后才利用canalClient来处理相关数据(数据同步需要阿里的otter中间件,基于canal)
mysql的几种binlog
MySQL 5.7.7 之前，binlog 的默认格式都是 STATEMENT，在 5.7.7 及更高版本中，binlog_format 的默认值才是 ROW
statement
语句级,binlog惠济路每一次执行写操作的语句.相对于row模式更节省空间,但是可能产生不一致性update tt set create_data=now(),如果用binlog日志进行恢复,由于执行时间不同可能产生的数据就不同
row
行级,binlog会记录每次操作后的变化
有点:保持数据的绝对一致性.因为不管sql是什么什么,引用了什么函数,他只记录执行后的结果
缺点:占用空间较大
mixed
statement的升级版,一定程度上解决了,因为一些情况造成的statement模式不一致的问题,默认还是statement,在某些情况下,譬如当函数中包含uuid时,包含aoti_increment字段被更新时,执行insert Delay语句时,会按照row的方式进行处理
优点:节省空间的同事兼顾了一定的一致性
缺点:还有极个别情况依旧会造成不一致,另外statement和mixed对于需要对binlog的监控情况都不方便
综上所述,canel想做监控分析,选择row格式比较合适
mysql的主从同步
- master主库改变记录,写到二进制日志中
- slave从库向mysql master发送dump协议,将master主库的binary log events拷贝到它的中继日志(relay log)
- slave 从库读取并重做中继日志中的事件,改变的数据同步到自己的数据库
canal就是把自己伪装成slave,假装从master复制数据
使用场景
canal是阿里otter中间件的一部分
场景1:更新缓存
场景2:抓去业务表的新增变化数据,用于实时统计
canal有kafka,Tcp,rocketMq三种模式
datax和canal对比
datax和canal都是阿里巴巴开开源的数据同步组件/工具，但是二者在功能架构、使用场景上又有些区别。我刚接触到这两个组件的时候，经常混淆他们，不太能分清楚他们各自的使用场景。今天这篇文章就打算彻底对比下两者的共同点和差异。
DataX 是阿里巴巴开源的离线数据同步工具/平台，内置实现了包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各种异构数据源之间高效的数据同步功能。
canal译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费。
从上面两段描述，我们可以了解到二者在使用场景上的区别，虽然都是数据传输工具，但datax主要是离线的场景，而canal是实时的场景。
datax
datax的网路传输拓补图如下
从上图可以看出，datax其实是起到了一个中间的传输桥梁的角色。多个数据源之间传输是个网状的拓扑结构，但是接入了datax后，可以变成一个星状的结构，简化了整个传输的模型。
这幅图是datax的总体架构图,可以看到datax采用Framework + plugin架构构建。
其中Framework处理了缓冲，限流，并发，上下文加载等技术问题。
而plugin就牛逼了，它提供了超强的扩展能力。将数据源读取和写入抽象成为Reader/Writer接口，纳入到整个同步框架中。如果内置的plugin无法满足我们的场景，开发者可以自己编写plugin定制功能。
开发者实现自己的插件非常简单，仅需实现对数据处理系统的访问即可，因为核心技术部分framework已经帮我们做好了。
核心架构如图
我看到这幅图的第一反应就是，跟flink有点像，事实上他们确实有很多相似的地方。对于一个任务，datax采用的是单进程+多线程的模式。流程如下：
DataX完成单个数据同步的作业，我们称之为Job，DataX接受到一个Job之后，将启动一个进程来完成整个作业同步过程。DataX Job模块是单个作业的中枢管理节点，承担了数据清理、子任务切分(将单一作业计算转化为多个子Task)、TaskGroup管理等功能。
DataXJob启动后，会根据不同的源端切分策略，将Job切分成多个小的Task(子任务)，以便于并发执行。Task便是DataX作业的最小单元，每一个Task都会负责一部分数据的同步工作。
切分多个Task之后，DataX Job会调用Scheduler模块，根据配置的并发数据量，将拆分成的Task重新组合，组装成TaskGroup(任务组)。每一个TaskGroup负责以一定的并发运行完毕分配好的所有Task，默认单个任务组的并发数量为5。
每一个Task都由TaskGroup负责启动，Task启动后，会固定启动Reader—>Channel—>Writer的线程来完成任务同步工作。
DataX作业运行起来之后， Job监控并等待多个TaskGroup模块任务完成，等待所有TaskGroup任务完成后Job成功退出。否则，异常退出，进程退出值非0。
举例来说，用户提交了一个DataX作业，并且配置了20个并发，目的是将一个100张分表的mysql数据同步到odps里面。DataX的调度决策思路是：
DataXJob根据分库分表切分成了100个Task。
根据20个并发，DataX计算共需要分配4个TaskGroup。（20/5=4,5是单个taskgroup默认使用的并发数量）
4个TaskGroup平分切分好的100个Task，每一个TaskGroup负责以5个并发共计运行25个Task。
Canal
架构图
canal的数据源只支持mysql，这点需要特别注意，这也限制了它的使用场景。
上图是mysql主从复制的原理图：
MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，可以通过 show binlog events 进行查看)
MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据
Canal 伪装成 MySQL 从节点，mySQL master 会推送 binary log 给canal，canal读取 MySQL binlog的变更信息并生成消息，客户端订阅这些数据变更消息，处理并存储。只要开发一个 Canal客户端就可以解析出MySQL的操作，再将这些数据发送到大数据流计算处理引擎，即可以实现对 MySQL 实时处理。
canal自身帮我们做了很多事，这样我们自己写的客户端才能更简单，更专注于业务。