Flink CDC-2.0 未来可期

概念

        一句话: 面向数据库的变更，是一种用于捕获数据库中数据变更的技术. 做技术的小伙伴们都懂,概念我不多说~

目前cdc 组件的特性比较

应用场景

数据同步 

数据分发

数据采集

目前的痛点

Flink CDC 底层封装了 Debezium， Debezium 同步一张表分为两个阶段:

      全量阶段: 查询当前表中所有记录

     增量阶段:从 binlog 消费变更数据

那么,flink cdc 目前就会有如下的痛点. 因为debezium也是一样的

如果再细剖一下为什么会是痛点,我们重点来分析一下, debezium对数据库锁的细节

研究可以参考 锁

FLINK FLIP-27

借鉴 Netflix

https://arxiv.org/pdf/2010.12597v1.pdf
https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface

Flink CDC 2.0的设计

核心目标: 

做到无锁的情况下,保证数据的一致性,并且能够并发高效的同步

核心思路

         Chunk 切片+Chunk读取

我的理解是:

        比如对于binlog,旧的cdc 是加一个全局锁,先同步全量,然后再捕获增量数据,这样做速度慢,并且在锁的同时会新增无数其他的烦恼.

        而flinkCDC 2.0的设计思路是:

        不加锁,先全量的读取将数据做chunk切片(按照主键)分成很多的片段,不同片段的区间做成左闭右开,.... ,并标记每一个chunk的低位点和高位点. 

        mysql 变更的数据,我们也叫增量数据根据算法,刚好落在某一个chunk的区间中,如图所示,那么这个chunk区间将做以下的汇聚,记录最后 一次的操作,这里简单理解成merge,

 如果Flink CDC 2.0 能保证全量里每个chunk的数据一致,同时也能保证update的增量数据按主键规则,落到指定的chunk中,并且最终结果数据一致,那么可以推断能保证表的数据一致性,

        那么库的一致性也就完成,我们的flink CDC 2.0的核心设计思路如此,我上面的分析是根据最近 flink meetup 中的徐榜江老师经常的讲解得出的心得笔记体会.
ppt分享详情请文档 链接：http://note.youdao.com/noteshare?id=d24e015c9fa389a9b2cecb0efc6e208f&sub=0A979601178643F6A4CE08A727B02182MySQL-CDC 2.0

https://github.com/ververica/flink-cdc-connectors/pull/233