0 前言
程序在 Flink 集群运行，某个算子因为某些原因出现故障，如何处理
在故障恢复后，如何保证数据状态，和故障发生之前的数据状态一致?
1 什么是 checkpoint(检查点)?
Checkpoint 能生成快照(Snapshot)。
若 Flink 程序崩溃，重新运行程序时可以有选择地从这些快照进行恢复。
Checkpoint 是 Flink 可靠性的基石。
2 Checkpoint V.S State
- State 指某个算子的数据状态，保存在堆内存
- Checkpoint 指所有算子的数据状态，持久化保存
3 什么是savepoint(保存点)?
基于 checkpoint 机制的快照。
4 Checkpoint V.S Savepoint
Checkpoint 是 自动容错恢复机制，Savepoint 某个时间点的全局状态镜像
Checkpoint 是 Flink 系统行为 。Savepoint 是用户触发
Checkpoint 默认程序删除。Savepoint 会一直保存
5 数据流快照最简单的流程
- 暂停处理新流入数据，将新数据缓存起来
- 将算子任务的本地状态数据拷贝到一个远程的持久化存储上
- 继续处理新流入的数据，包括刚才缓存起来的数据
6 Flink slot 和并行度
设置合理的并行度能够加快数据的处理
Flink 每个算子都可以设置并行度
Slot 使得 taskmanager 具有并发执行的能力
Flink 任务和子任务
从 Source 到 sink，每当并行度发生变化或者数据分组( keyBy)，就会产生任务。
一个任务的并行度为 N，就会有 N 个子任务。
7 Checkpoint 分布式快照流程
第1步
要实现分布式快照，最关键的是能够将数据流切分。Flink 中使用 Checkpoint Barrier(检查点分割线)来切分数据流
当 Source 子任务收到 Checkpoint 请求，该算子会对自己的数据状态保存快照。
向自己的下一个算子发送 Checkpoint Barrier，下一个算子只有收到上一个算子广播过来的 Checkpoint Barrier，才进行快照保存。
第2步
当 Sink 算子已经收到所有上游的 Checkpoint Barrie 时，进行以下 2 步操作：
- 保存自己的数据状态
- 并直接通知检查点协调器
检查点协调器在收集所有的 task 通知后，就认为这次的 Checkpoint 全局完成了。
下游算子有多个数据流输入，啥时才 checkpoint？
这就涉及到Barrie对齐机制，保证了 Checkpoint 数据状态的精确一致。
第1步：下一个算子某个通道接收了第一个ID为n的 Checkpoint Barrie
这个算子其他通道的ID 为n的 Checkpoint Barrie 还没到达
第2步：该算子将第一个ID为n的 Checkpoint Barrie 缓存
该个算子继续处理其他通道的ID为n的 Checkpoint Barrie
第3步:
该个算子所有通道的ID 为n的 Checkpoint Barrie 到达后
该算子执行快照
不进行 Barrier 对齐可以吗？
8 Checkpoint咋保证数据状态的一致性？
Flink内置的数据状态一致性
端到端的数据状态一致性
Flink 系统内部的数据状态一致性
AT-MOST-ONCE(最多一次，已废除)
发生故障，可能会丢失数据
AT-LEAST-ONCE(至少一次)
发生故障，可能会有重复数据。
EXACTLY-ONCE(精确一次)
发生故障，能保证不丢失数据，也没有重复数据
KafkaSink 总共支持三种不同的语义保证（DeliveryGuarantee）。对于 DeliveryGuarantee.AT_LEAST_ONCE 和 DeliveryGuarantee.EXACTLY_ONCE，Flink checkpoint 必须启用。默认情况下 KafkaSink 使用 DeliveryGuarantee.NONE。
DeliveryGuarantee.NONE不提供任何保证：消息有可能会因 Kafka broker 的原因发生丢失或因 Flink 的故障发生重复。DeliveryGuarantee.AT_LEAST_ONCE: sink 在 checkpoint 时会等待 Kafka 缓冲区中的数据全部被 Kafka producer 确认。消息不会因 Kafka broker 端发生的事件而丢失，但可能会在 Flink 重启时重复，因为 Flink 会重新处理旧数据。DeliveryGuarantee.EXACTLY_ONCE: 该模式下，Kafka sink 会将所有数据通过在 checkpoint 时提交的事务写入。因此，如果 consumer 只读取已提交的数据（参见 Kafka consumer 配置isolation.level），在 Flink 发生重启时不会发生数据重复。然而这会使数据在 checkpoint 完成时才会可见，因此按需调整 checkpoint 间隔。请确认事务 ID 的前缀（transactionIdPrefix）对不同的应用是唯一的，以保证不同作业的事务 不会互相影响！此外，强烈建议将 Kafka 的事务超时时间调整至远大于 checkpoint 最大间隔 + 最大重启时间，否则 Kafka 对未提交事务的过期处理会导致数据丢失。
9 Data Source 和 Sink 的容错保证
当程序出现错误的时候，Flink 的容错机制能恢复并继续运行程序。这种错误包括机器硬件故障、网络故障、瞬态程序故障等。
只有当 source 参与快照机制，Flink 才能保证对自定义状态的精确一次更新。下表列举了 Flink 与其自带连接器的状态更新的保证。
| Source | Guarantees | Notes |
|---|---|---|
| Apache Kafka | 精确一次 | 根据你的版本用恰当的 Kafka 连接器 |
| Amazon Kinesis Data Streams | 精确一次 | |
| RabbitMQ | 至多一次 (v 0.10) / 精确一次 (v 1.0) | |
| Google PubSub | 至少一次 | |
| Collections | 精确一次 | |
| Files | 精确一次 | |
| Sockets | 至多一次 |
为保证端到端精确一次的数据交付（在精确一次的状态语义上更进一步），sink需要参与 checkpointing 机制。下表列举了 Flink 与其自带 sink 的交付保证（假设精确一次状态更新）。
| Sink | Guarantees | Notes |
|---|---|---|
| Elasticsearch | 至少一次 | |
| Opensearch | 至少一次 | |
| Kafka producer | 至少一次 / 精确一次 | 当使用事务生产者时，保证精确一次 (v 0.11+) |
| Cassandra sink | 至少一次 / 精确一次 | 只有当更新是幂等时，保证精确一次 |
| Amazon DynamoDB | 至少一次 | |
| Amazon Kinesis Data Streams | 至少一次 | |
| Amazon Kinesis Data Firehose | 至少一次 | |
| File sinks | 精确一次 | |
| Socket sinks | 至少一次 | |
| Standard output | 至少一次 | |
| Redis sink | 至少一次 |
关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都架构师，多家大厂后端一线研发经验，在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。
各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。
负责：
- 中央/分销预订系统性能优化
- 活动&券等营销中台建设
- 交易平台及数据中台等架构和开发设计
- 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
- LLM Agent应用开发
- 区块链应用开发
- 大数据开发挖掘经验
- 推荐系统项目
目前主攻市级软件项目设计、构建服务全社会的应用系统。
参考：