实时项目3(交易额需求)
1.0 采集数据
1.1 框架流程
1.2 Canal 入门
1.2.1 什么是 Canal
阿里巴巴B2B公司，因为业务的特性，卖家主要集中在国内，买家主要集中在国外，所以衍生出了杭州和美国异地机房的需求，从2010年开始，阿里系公司开始逐步的尝试基于数据库的日志解析，获取增量变更进行同步，由此衍生出了增量订阅&消费的业务。
Canal是用Java开发的基于数据库增量日志解析，提供增量数据订阅&消费的中间件。目前，Canal主要支持了MySQL的Binlog解析，解析完成后才利用Canal Client 用来处理获得的相关数据。（数据库同步需要阿里的otter中间件，基于Canal）。
1.2.2 使用场景
- 原始场景： 阿里Otter中间件的一部分
- 常见场景1：更新缓存
- 场景2：抓取业务数据新增变化表，用于制作拉链表**(没有创建时间的时候只能使用canal)**
拉链表主要是为了更简单的获取历史数据,获取数据最好的方式当然还是全量,但是用户表数据比较庞大,而且它属于缓慢更新维,没有必要用全量,我们用拉链表就可以了.
- 场景3：抓取业务表的新增变化数据，用于制作实时统计。
1.2.3 Canal的工作原理
Canal的工作原理很简单，就是把自己伪装成Slave，假装从Master复制数据
1.2.4 MySQL的Binary log
1.2.4.1 什么是Bin log
- 记录了所有的DDL和DML(除了数据查询语句)语句
- 使用场景:主从复制和数据恢复
1.2.4.2 Bin log的开启
在MySQL的配置文件(Linux: /etc/my.cnf , Windows: \my.ini)下,修改配置在[mysqld] 区块设置/添加
log-bin=mysql-bin
这个表示binlog日志的前缀是mysql-bin，以后生成的日志文件就是 mysql-bin.123456 的文件后面的数字按顺序生成。每次mysql重启或者到达单个文件大小的阈值时，新生一个文件，按顺序编号。
1.2.4.3 Bin log的分类设置
-
statement:语句类型
- 记录每次一执行写操作的语句
- insert into t1 values(“1”,“zhangsan”);
- 优点:数据量小
- 缺点:特定情况下,数据的一致性没发保证(譬如随机数)
-
row:行数据类型
- 记录每次操作后每行记录的变化
- “1”,“zhangsan”,DB,t1,insert
- 优点:数据的一致性
- 缺点:数据量大
-
mixed:混合类型
- statement的升级版，一定程度上解决了，因为一些情况而造成的statement模式不一致问题
在此场景中,canal 没有执行引擎,不能恢复成数据,只能使用row级别
还可以在配置文件中直接传入kafka,但是所有信息糅合在一个topic中,还是需要写代码解析出来然后分发各个topic