Flink学习11-flink实现端到端精准一次消费(EOS)原理

flink实现端到端精准一次消费(EOS)

1、At-least-once 与 Exactly-Once区别

理解barrier:

    checkpoint中的核心概念，多个barrier被插入到数据流中,然后作为数据流的一部分随着数据流动。barrier相当于给这
    个流打上一个标记，当带有标记的流进入下游算子时，该算子会进行快照。同一时间可以有来源于多个不同快照的多个
    barrier,这意味着可以并发的出现不同的快照

Exactly-Once

    barrier对齐：
    当一个算子上游有两条或多条输入时，在进行Checkpoint时可能会出现两条流中数据流速不一样，导致多条流同一批
    次的Barrier到达下游算子的时间不一致， 此时快的Barrier到达下游算子后，此Barrier之后到达的数据将会放到缓冲区，
    不会进行处理。等到其他流慢的Barrier到达后，此算子才进行checkpoint，然后把状态保存到状态后端。这就是Barrier
    的对齐机制。
    优缺点
        1）优点：状态后端保存数据少。
        2）缺点：
            ①延迟性高(快的Barrier到达后会阻塞此条流的数据处理)
            ②当作业出现反压时，会加剧作业的反压(当出现反压时，数据本身就处理不过来，此时某条流的数据又阻塞了所以
            就会加剧反压。)
            ③整体chenkpoint时间变长(因为反压会导致数据流速变慢，导致Barrier流的也慢，所以就会使得整体chenkpoint时
            间变长)。
    barrier不对齐（flink1.11之后）：
        当流速快的Barrier到达下游算子的input buffer后，此时会把这个Barrier插队到此下游算子的output buffer最前面，然后
        把这个Barrier发送给之后的算子，同时对自身进行快照，这时的快照内容就是当时的状态以及当时所有input buffer和
        output buffer以及流速慢的Barrier之前的数据都会保存到状态后端当中。当之后恢复到此次checkpoint的时候，不对齐
        的数据会重新恢复到各个流中，虽然会重新进行计算，但是此时的状态也是未计算之前的状态。
    优缺点
        1）优点：①加快checkpoint的进行②当作业出现反压时不会造成反压加剧。
        2）缺点：①状态后端保存数据多②进行状态恢复的时比较慢。

At-least-once:

    barrier不对齐：
        这个不对齐和上边的精准一次消费不对齐机制是不一样的。当流速快的Barrier流到下游算子当中，
        此时不理会此Barrier，正常进行后续数据的计算。当流速慢的Barrier到来的时候，此时进行快照,
        会把流速快的那条流中相同Barrier后的数据也进行计算一部分，然后把计算完的状态保存到状态
        后端，之后进行状态恢复时，会把Barrier之后的数据进行重复, 而此时状态的结果是包含一部分
        Barrier之后的数据的 ，此时就会造成数据的重复消费问题。
    优缺点
        1）优点：①不会阻塞数据，延迟低。
        2）缺点：①造成数据的重复消费问题。

2、kafka事务特性

kafka0.11版本后开启了事务，kafka事务的特性：原子性
原子性：多个topic的多个papartition实现原子性写入
flink在消费到kafka数据后就会开启事务，数据正常写入到kafka分区中，但日志标记为未提交

3、flink source端实现Exactly-Once

source端实现Exactly once只需要将数据消费的偏移量保存在state backend中即可

4、flink sink端实现Exactly-Once

flink在1.4版本后引入两阶段提交的功能（TwoPhaseCommitSinkFunction），主要解决flink数据到sink端的Exactly-Once。
引入这样的一个功能主要在于，flink无法监控外部数据源系统的数据处理状态。所以精准一次处理语义必须也要应用于Flink
写入数据的外部系统，故这些外部系统必须提供一种手段允许提交或回滚这些写入操作。Kafka 0.11版本正式发布了对于事
务的支持，这是与Kafka交互的Flink应用要实现端到端精准一次语义的必要条件

原理：

    两阶段提交将提交过程划分为连续的两个阶段：表决阶段（Voting）和提交阶段（Commit）。两阶段提交协议中有两个重
    要角色，协调者（Coordinator）和参与者（Participant），其中协调者只有一个，起到分布式事务的协调管理作用，参与者
    有多个。
    第一阶段：表决阶段
        协调者向所有参与者发送一个 VOTE_REQUEST 消息。
        当参与者接收到 VOTE_REQUEST 消息，向协调者发送 VOTE_COMMIT 消息作为回应，告诉协调者自己已经做好准备
        提交准备，如果参与者没有准备好或遇到其他故障，就返回一个 VOTE_ABORT 消息，告诉协调者目前无法提交事务。
    第二阶段：提交阶段
        协调者收集来自各个参与者的表决消息。如果所有参与者一致认为可以提交事务，那么协调者决定事务的最终提交，在此
        情形下协调者向所有参与者发送一个 GLOBAL_COMMIT 消息，通知参与者进行本地提交；如果所有参与者中有任意一个
        返回消息是 VOTE_ABORT，协调者就会取消事务，向所有参与者广播一条 GLOBAL_ABORT 消息通知所有的参与者取消
        事务。每个提交了表决信息的参与者等候协调者返回消息，如果参与者接收到一个 GLOBAL_COMMIT 消息，那么参与者
        提交本地事务，否则如果接收到 GLOBAL_ABORT 消息，则参与者取消本地事务。

flink两阶段提交流程:：

    pre-commit阶段:
        从source开始，flink内部transformation算子遇到带有checkpoint barrier标识的流时候都会把状态保存在checkpoint里。当数据流到达sink时，首先状态保存至checkpoint,然后把数据写入到下游kafka数据源，同时事务
        预提交，将数据标记为未提交状态（此时数据没有正式消费）。当所有的算子checkpoint状态保存完毕，jobmanager（协调者）会通知需要保存状态的算子（参与者）本次checkpoint保存完毕。此时pre-commit阶段完成。
    commit阶段:
        当参与者（主要是sink端）收到协调者的确认通知后，会提交外部事务，kafka中被标记未提交的数据变为已提交，然后事务关闭，数据被正式消费。