这是我参与「第四届青训营 」笔记创作活动的的第8天
Exactly -Once和Checkpoint
状态快照与恢复
为了保证对数据语义不丢不重，设置故障恢复的时间点
回到故障发生的时间点，恢复该时刻的状态
制作快照的时间点
状态恢复的时间点:需要等待所有处理逻辑消费完成source保留状态及之前的数据
在数据上游的数据都被下游消费完了之后，才认为状态是正确的、完备的
一个简单的快照制作算法:
1.暂停处理输入的数据;
2.等待后续所有处理算子消费当前已经输入的数据;
3.待2处理完后，作业所有算子复制自己的状态并保存到远端可靠存储;
4.恢复对输入数据的处理
Chandy-Lamport算法
快照制作的开始
每一个source算子都接收到JM发送的Checkpoint Barrier标识状态快照制作的开始
Source算子的处理
各个source保存自己状态后，向所有连接的下游继续发送Checkpoint Barrier, 同时告知JM自已状态已经制作完成
source算子确认自己状态完成后即可继续进行下一步数据处理
Barrier Alignment
- 算子会等待所有上游的barrier 到达后才开始快照的制作;
- 已经制作完成的上游算子会继续处理数据，并不会被下游算子制作快照的过程阻塞
快照制作和处理数据的解耦
sink算子没有下游，当某一个sink先接收到barriers时，sink会往JM处发送信息告知状态已完成，当所有的算子状态都完成了，才恢复数据处理
checkpoint的结束
所有算子都告知JM状态制作完成后，整个Checkpoint就结束了
Checkpoint对作业性能的影响
- 解耦了快照制作和数据处理过程，各个算子制作完成状态快照后就可以正常处理数据，不用等下游算子制作制作完成快照;
- 在快照制作和Barrier Alignment过程中需要暂停处理数据，仍然会增加数据处理延迟;
- 快照保存到远端也有可能极为耗时。
Flink端到端Exactly-Once实现
端到端Exactly-Once语义
- Checkpoint 能保证每条数据都对各个有状态的算子更新一次，sink 输出算子仍然可能下发重复的数据;
2.严格意义的端到端的Exactly-once语义需要特殊的sink算子实现。
两阶段提交协议
在多个节点参与执行的分布式系统中，为了协调每个节点都能同时执行或者回滚某个事务性的操作，引入了一个中心节点来统一处理所有节 点的执行逻辑，这个中心节点叫做协作者(coordinator) ，被中心节点调度的其他业务节点叫做参与者(participant) 。
两阶段提交协议(一)---预提交阶段
1.协作者向所有参与者发送一个commit消息;
2.每个参与的协作者收到消息后，执行事务，但是不真正提交;
不对下游可见
3.若事务成功执行完成，发送一个成功的消息 (vote yes) ;执行失败，则发送一个失败的消息(vote no)
两阶段提交协议(二) --- 提交阶段
若协作者成功接收到所有的参与者vote yes的消息:
前提：1、所有协作者2、vote yes
1.协作者向所有参与者发送一个 commit消息;
2.每个收到commit消息的参与者释放执行事务所需的资源，并结束这次事务的执行;
3.完成步骤2后，参与者发送一个ack消息给协作者:
4.协作者收到所有参与者的ack消息后，标识该事务执行完成。
全部执行操作或全部不执行操作
Flink中的2PC Sink
协作者向参与者发送barrier
协作者接收到barrier后，执行状态制作，向JM发送执行状态信息（执行成功/执行失败），若执行成功再向下游发送执行后的barrier
第一阶段提交协议
所有算子都执行完成并成功，sink往kafka发送commit
Flink两阶段提交总结
1.事务开启:在sink task向下游写数据之前，均会开启一个事务，后续所有写数据的操作均在这个事务中执行，事务未提交前，事务写入的数据下游不可读;
2.预提交阶段: JobManager 开始下发Checkpoint Barrier,当各个处理逻辑接收到barrier后停止处理后续数据，对当前状态制作快照，此时sink也不在当前事务下继续处理数据(处理后续的数据需要新打开下一个事务)。状态制作成功则向JM成功的消息，失败则发送失败的消息;
3.提交阶段:若JM收到所有预提交成功的消息，则向所有处理逻辑(包括sink)发送可以提交此次事务的消息，sink 接收到此消息后，则完成此次事务的提交，此时下游可以读到这次事务写入的数据;若JM有收到预提交失败的消息，则通知所有处理逻辑回滚这次事务的操作，此时sink则丢弃这次事务提交的数据下。
