flink connector怎么保证数据的一致性的操作
1.flink的operator是可以通过相关的配置来保证operator的一致性的，这个不是主要讨论的问题；
2.下面我们主要讨论的问题是在数据层面，flink是如何保证数据的基准的一次性的消费的。
首先，我们需要有如下的前提，我们认为程序是会出错的，并且flink的处理任务是会报错的。那么我们已经可以获取得到算子的状态数据了，那么我们小得的数据是如何能够实现查找的。下面是一些典型的框架的处理思路的。我们首先讨论的是数据的source侧，然后处理的是数据的sink的，看一下如何保证数据的exactly-once的消费的
source侧：
1）kafka，rabiitmq:source端维护对应的offset就可以实现数据的精准的一次性的消费的。对应的维护相关的offset就可以了，根据offset就可以实现精准的offset的消费的。
2）mysql的cdc的connector对应的也是存储了相关的offset来保证对应的excatly-once的数据消费的，对应的文件是BinlogOffset ，对应的是结合了offset加上相关的snapshot机制来实现的。mysql的cdc的话只能作为source来操作的，如果想要对应的sink操作的话，需要的是flink的jdbc的connector的机制来操作的。flink的底层是使用Debezium来读取mysql的changlog的数据，而不是使用canel来读取数据的。mysql的cdc是采用单线程读取数据的。cdc是不会动态的捕获数据库的schema的变更的。
3）mongodb的cdc：mongodb的cdc利用的是mongodb的新特性的，对应的是采用相关的Change Stream来发送消息时间，订阅消息完成数据订阅操作的。需要的是mongodb服务器本身支持对应的cdc机制的。这个是mongodb本身的机制来保证数据的不会重复消费的，对应的底层也是存在有oplog的依赖的。
4）ocean base的cdc:ocean base对应的也是提供了相关的cdc的功能实现的，对应的是采用liboblog日志的方式来操作的，获取到对应的redo-log，将其转换成为对应的消息发送到kakfka等进行消费。
上面的几种方式是类似的，上面的集中cdc的操作最终还是基于底层的Debezium的引擎来完成相关的实现操作的，底层是维护了大量的offsetState以及schemaRecordsState等的相关的信息的。保证了source端的数据满足精准的exactly-once的特性的。cdc的特性适合作为source端执行操作的。
**还需要注意的是flink的source 端的exactly-once还需要source端是支持两阶段协议的。flink上面各种机制只是保证了自身的exactly-once的
sink端的数据保证exactly-once的特性的：sink端的操作需要对应的服务端提供相关的两阶段的协议提交提交来保证exactly-once的语义的。**这个是很关键的。
总结:flink的exactly-once的保证，保证的是flink自身的exactly-once的机制的，需要flink从source到sink的exactly-once的话，需要的是source端以及sink端实现相关的分布式事务的，对应的是一致性的机制实现的。如果可以的话，部署成为单个的节点的话，可能会比较好的解决相关的难点。
flink kafka的exactly-once需要source以及sink很好的支持exactly-once，并且很好的配置的。
