这是我参与「第四届青训营 」笔记创作活动的第3天
> Exactly Once 语义在 Flink 中的实现
数据流和动态表
1. 传统SQL和流处理
想到问题：如何在实时流中定义表
2. 数据流和动态表转换
Stream -> Dynamic Table -> Continuous Query （连续查询）-> Dynamic Table -> Stream
流转化为表，表再转化为流
在流上定义表：插入单击流记录，结果表将不断增长
连续查询
动态表->动态表
- 查询从不终止
- 查询结果会不断更新，产生一个新的动态表
在任何时候，连续查询的结果在语义上与以批处理模式在输入表快照上执行的相同查询的结果相同
查询产生仅追加数据的动态表
两种连续查询对比：
1.第一个查询更新先前输出的结果，即定义结果表的changelog 流包含INSERT和UPDATE操作
2.第二个查询只附加到结果表，即结果表的changelog 流只包含INSERT操作
状态
需要存储每个用户的 URL 计数，以便能够增加该计数并在输入表接收新行时发送新结果
不同数据处理保证的语义
- At-most-once：啥也不做
- At-least-once：至少处理一次
- Exactly-once：最严格的处理语义
Exactly-Once和Checkpoint
状态快照与恢复
设置故障恢复时间点，就像电脑定时快照备份一样
制作快照的时间点
状态恢复的时间点：需要等待所有处理逻辑消费完成source 保留状态及之前的数据
Chandy-Lamport算法
快照制作的开始
每一个 source 算子都接收到 JM 发送的 Checkpoint Barrier 标识状态快照制作的开始
（Checkpoint Barrier将数据分成不同数据段）
Source 算子的处理
各个 source 保存自己状态后，向所有连接的下游继续发送Checkpoint Barier，同时告知 JM 自己状态已经制作完成
Barrier Alignment
- 算子会等待所有上游的barrier到达后才开始快照的制作
- 已经制作完成的上游算子会继续处理数据，并不会被下游算子制作快照的过程阻塞
快照制作和处理数据的解耦
端到端Exactly-Once实现
端到端 Exactly-once 语义
-
Checkpoint 能保证每条数据都对各个有状态的算子更新一次，sink输出算子仍然可能下发重复的数据
-
严格意义的端到端的Exactly-once语义需要特殊的sink 算子实现
两阶段提交协议
在多个节点参与执行的分布式系统中，为了协调每个节点都能同时执行或者回滚某个事务性的操作，引入了一个中心节点来统一处理所有节点的执行逻辑，中心节点--协作者（coordinator）被中心节点调度的其他业务节点--参与者（participant）
- 预提交阶段
- 提交阶段
