Datax CDC 可靠 channel

1. 背景

可靠 channel，可确认的分布式持久数据(Record)的 channel，Channel 不可靠对于 CDC 是致命的，丢失数据；但对于全量同步可以接受，全量同步故障转移后，整个分片重新同步。可靠 channel 对于数据量比较大，没有分片的情况也非常有用，相当于断点续传的能力，但对性能有一定影响

2. 参考和术语

CDC change data capture 数据变更抓获

CDC增量同步框架与关系/neo4j增量同步设计

3. 分布式 SETL 模块和规划

下图介绍 SETL 模块和规划

setl-rbt 全量同步组件，datax 组件，接入分布式调度，实现高性能的全量同步

setl-cdc cdc 增量同步 datax 组件，接入分布式时间槽实现高可靠增量，后续规划接入 kafka connect

setl-stream 研发中，流式 etl，引入 kafka connect，实现高吞吐低延时的增量同步

config-center 配置中心，datax 原生使用本地文件配置，配置中心摆脱本地文件限制，实现分布式系统的必要基础设施

sanner schema 扫描，辅助数据的同步

4. datax 原理介绍

*官方图，Transport 处是 Channel，本人觉得不太准确，应为 Transport

> 作业分解为任务，任务分组，最后调度器调度任务(组)

*作业分片和任务分组没有在高可用中

> 调度器负责分派资源执行任务(组)，TaskEecutor 执行任务

> transport 包括数据交换(exchanger)，转换(transformer)，交换数据字节数/记录(record)数的统计(channel)

5. CDC 原生 Datax channel 分析

整个数据链路包括 2 部分，

第一段，CDC 变更事件推送到 reader，reader 写到 Exchanger(Channel)*成功后 ack CDC

第二段，writer 从 Exchanger 拉取数据变更，同步到目标存储

另外，Channel 承担流量统计和流控的职责

可以看到，第二段是不可靠的，MemoryChannel 底层使用内存 ArrayBlockingQueue 存放数据，datax 节点崩溃，故障转移后，原节点 Channel 的数据将丢失

*Buffered 类型 Exchanger 缓存 Record，批量提交，存在丢失可能，可靠 Channel 需要非 buffered Exchange 配合

6 可靠 channel 设计原理解释

1) 方案 1-推模式

数据链路同样的两个阶段，不同的是第二阶段，channel 引入 mq 作为持久存储，提供可确认，方案改变原数据链路，数据从 mq 获取，writer 依赖 mq，从而也改变了 writer 开发模型，6.1/6.2 只是激活 pull 统计，获取的数据并不使用。6.1/6.2 放在 5~7 之间，是为了 pull 统计更准确

2) 方案 2

同方案 1，引入 mq，不同的是，mq 作为本地 queue 持久存储，Channel 封装起来，writer 不需要依赖 mq，数据链路与原生一样，主动获取 mq 消息。本方案保持数据链路形态，即 writer 通过 RecordReceiver 获取 Record。缺点，Exchanger/Channel 增加 ack 方法，主动消费，涉及消费异步 ack 问题

3）推模式下channel统计

推模式下，旁路读取record，读取record通过消息引擎，需要通知channel读取了record，channel计算record的大小，发起统计

RecordReceiver

           public void byPassReader(Record record);

读取接口增加byPassReader方法