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配合

*Exchanger拆分为InBound/OutBound比较合理

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方法