Flink中ExactlyOnce与AtleastOnce

理解这两种语义,首先要了解Barrier

流的barrier是Flink的Checkpoint中的一个核心概念.多个barrier被插入到数据流中,然后作为数据流的一部分随着数据流动(有点类似于Watermark),这些barrier不会跨越流中的数据

        每个barrier会把数据流分成两部分:一部分数据进入当前的快照,另一部分数据进入下一个快照.每个barrier携带者快照的id.barrier不会暂停数据的流动,所以非常轻量级

        所以说:在流中,同一时间可以有来源于多个不同快照的多个barrier,这意味着可以并发的出现不同的快照。

   在上图中,数据流中插入了barrier,意味当barrier流入到下游的算子(例如Map时),Map即需进行快照；

ExactlyOnce--精准一次性--Barrier对齐

        在多并行度下,如果想要实现精准一次性,需要使用Barrier对齐，当 job graph 中的每个 operator 接收到 barriers 时，它就会记录下其状态。拥有两个输入流的 Operators（例如CoProcessFunction)会执行 barrier 对齐(barrier alignment) 以便当前快照能够包含消费两个输入流 barrier 之前（但不超过）的所有 events 而产生的状态.

        那这句话怎么理解呢?

 在上图中,上游有两个并行度,中间都被Source Task安插了barrier,目的地是下游的Map Task

随着数据的流动,Source①的barrier已经进入了Map中.重点来了

        此时因为规则是Barrier对齐,Map需要等待Source②的barrier也到达,才可以做快照

      并且为了保证barrier可以划分出明确的前后两个部分,在等待Source②的barrier到来的过程中,Source①流到Map的数据不会被处理

        那么有小朋友就会问了,那我不处理Source①流入的数据,那不就丢失数据了吗?

 其实我们是把 在等待Source②过程中,Source①流入的数据,放到了一个缓存区内,等到barrier对齐之后,再把他们读出来处理.

OK!这样的话原理就讲完了,来总结一下

1.当Map收到Source①的barrier id=n 时, 它就不能处理(但是可以接收)来自该流的任何数据记录，直到它从Source②所有输入接收到 barrier id=n 为止。否则，它会混合属于快照 id=n 的记录和属于快照 id=n 的记录。
2.接收到 barrier id=n 的流(数字流)暂时被搁置。从这些流接收的记录入输入缓冲区, 不会被处理。
3.图三中的 Checkpoint barrier id=n之后的数据 234已结到达了算子, 存入到输入缓冲区没有被处理, 只有等到Source②的Checkpoint barrier id=n到达之后才会开始处理.
4.一旦最后所有输入流都接收到 barrier id=n，Operator 就会把缓冲区中 pending 的输出数据发出去，然后把 CheckPoint barrier id=n 接着往下游发送。这里还会对自身进行快照。

AtleastOnce--至少一次--Barrier不对齐

        在了解这个Barrier不对齐之前,首先咱们得明确一个事实!!!

        就是咱们在恢复故障的时候,用的是最新的,完整的checkpoint

        也就是说,那些不完整的checkpoint是不能作为恢复的依据的

  看看看,不用等对齐,就可以向下流动,这个时候要是恢复故障,那不就是因为barrier id=n不完整

(下面的barrier还在路上呢!),所以这个checkpoint不可用,要用之前.完整的checkpoint

        所以你可以发现,这个二号小方块是不是又能被算一遍???
————————————————
版权声明：本文为CSDN博主「徐一闪_BigData」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zznanyou/article/details/121347608