这是我参与「第四届青训营 」笔记创作活动的的第3天
前言： 什么是Exactly Once？
倘若发生各种故障，事件也会被确保只会被流应用中的所有算子“恰好”处理一次。拿来实现“exactly-once”的有两种受欢迎的典型机制：1. 分布式快照/状态检查点（checkpointing） 2. At-least-once的事件投递加上消息去重 用来实现“exactly-once”的分布式快照/状态检查点方法是受到了Chandy-Lamport分布式快照算法1的启发。在这种机制中，流处理应用中的每一个算子的所有状态都会周期性地checkpointed。倘若系统发生了故障，每一个算子的所有状态都会回滚到最近的全局一致的检查点处。在回滚过程中，所有的处理都会暂停。Sources也会根据最近的检查点重置到正确到offset。整个流处理应用基本上倒回到最近的一致性状态，处理也可以从这个状态重新开始。
思维导图
根据思维导图分成四部分:数据流和动态表，Exactly Once和Checkpoint，端对端的ExactlyOnce的实现，Flink案例讲解。
数据流和动态图的转换
制作快照的时间点
Chandy-Lamport算法
Source 算子的处理
提交协议一预提交阶段
提交协议二提交阶段
总结：1.事务开启:在sink task向下游写数据之前，均会开启一个事务，后续所有写数据的操作均在这个事务中执行，事务未提交前，事务写入的数据下游不可读:2.预提交阶段: JobManager开始下发Checkpoint Barrier, 当各个处理逻辑接收到barier后停止处理后续数据，对当前状态制作快照，此时sink也不在当前事务下继续处理数据(处理后续的数据需要新打开下一个事务) 。状态制作成功则向JM成功的消息，失败则发送失败的消息;3.提交阶段: 若JM收到所有预提交成功的消息，则向所有处理逻辑(包括sink)发送可以提交此次事务的消息，sink 接收到此消息后，则完成此次事务的提交，此时下游可以读到这次事务写入的数据;若JM有收到预提交失败的消息，则通知所有处理逻辑回滚这次事务的操作，此时sink则丢弃这次事务提交的数据下。
个人思考：快照能方便我们在未保存的情况下减少工作上或学习上的失误而带来的损失。
