flink一致性

flink状态一致性的保证

• 一致性检查点（checkpoint）
• 端到端（end-to-end）状态一致性
• 端到端的精确一次（exactly-once）保证
• Flink+Kafka 端到端状态一致性的保证

一致性检查点（Checkpoints）

• Flink 使用了一种轻量级快照机制 —— 检查点（checkpoint）来保证 exactly-once 语义
• 有状态流应用的一致检查点，其实就是：所有任务的状态，在某个时间点的一份拷贝（一份快照）。而这个时间点，应该是所有任务都恰好处理完一个相同的输入数据的时候。
• 应用状态的一致检查点，是 Flink 故障恢复机制的核心

 

端到端（end-to-end）状态一致性

概念

• 目前我们看到的一致性保证都是由流处理器实现的，也就是说都是在 Flink 流处理器内部保证的；而在真实应用中，流处理应用除了流处理器以外还包含了数据源（例如 Kafka）和输出到持久化系统
• 端到端的一致性保证，意味着结果的正确性贯穿了整个流处理应用的始终；每一个组件都保证了它自己的一致性
• 整个端到端的一致性级别取决于所有组件中一致性最弱的组件

端到端 exactly-once

• 内部保证 —— checkpoint
• source 端 —— 可重设数据的读取位置
• sink 端 —— 从故障恢复时，数据不会重复写入外部系统
  • 幂等写入
  • 事务写入 预写日志和两阶段提交
  • hdfs文件

幂等写入（Idempotent Writes）

        所谓幂等操作，是说一个操作，可以重复执行很多次，但只导致一次结果更改，也就是说，后面再重复执行就不起作用了

事务写入（Transactional Writes）

事务（Transaction）

• 应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消
• 具有原子性：一个事务中的一系列的操作要么全部成功，要么一个都不做

实现思想：

• 构建的事务对应着 checkpoint，等到 checkpoint 真正完成的时候，才把所有对应的结果写入 sink 系统中

实现方式

• 预写日志
• 两阶段提交

预写日志（Write-Ahead-Log，WAL） 假事务 模拟事务,存在风险

• 把结果数据先当成状态保存，然后在收到 checkpoint 完成的通知时，一次性写入 sink 系统
• 简单易于实现，由于数据提前在状态后端中做了缓存，所以无论什么 sink 系统，都能用这种方式一批搞定
• DataStream API 提供了一个模板类：GenericWriteAheadSink，来实现这种事务性 sink

事务两阶段提交（Two-Phase-Commit，2PC） 真正的事务需要数据库支持

• 对于每个 checkpoint，sink 任务会启动一个事务，并将接下来所有接收的数据添加到事务里
• 然后将这些数据写入外部 sink 系统，但不提交它们 —— 这时只是“预提交”
• 当它收到 checkpoint 完成的通知时，它才正式提交事务，实现结果的真正写入
• 这种方式真正实现了 exactly-once，它需要一个提供事务支持的外部 sink 系统。Flink 提供了 TwoPhaseCommitSinkFunction 接口。
• 2PC 对外部 sink 系统的要求

• • 外部 sink 系统必须提供事务支持，或者 sink 任务必须能够模拟外部系统上的事务
  • 在 checkpoint 的间隔期间里，必须能够开启一个事务并接受数据写入
  • 在收到 checkpoint 完成的通知之前，事务必须是“等待提交”的状态。在故障恢复的情况下，这可能需要一些时间。如果这个时候sink系统关闭事务（例如超时了），那么未提交的数据就会丢失. 所以需要保持checkpoint超时时间与外部数据库事务超时时间一致
  • sink 任务必须能够在进程失败后恢复事务
  • 提交事务必须是幂等操作

不同 Source 和 Sink 的一致性保证

source \ sink	不可重置	可重置
任意（Any）	At-most-once	At-least-once
幂等	At-most-once	Exactly-once （故障恢复时会出现暂时不一致）
预写日志（WAL）	At-most-once	At-least-once
两阶段提交（2PC）	At-most-once	Exactly-once
StreamFileSink三种状态(类似事务)	At-most-once	Exactly-once

思考: hdfs既没有事务又没有幂等性flink是如何保证精准一次性的呢?

官网介绍

三种状态,并没有写明是是如何保证精准一次的

1. In-progress : The part file that is currently being written to is in-progress 正在写入
2. Pending : Closed (due to the specified rolling policy) in-progress files that are waiting to be committed 写入关闭
3. Finished : On successful checkpoints pending files transition to “Finished”  写入完成

StreamingFileSink源码注释

        If case of a failure, and in order to guarantee exactly-once semantics, the sink should roll back to the state it had when that last successful checkpoint occurred. To this end, when restoring, the restored files in pending state are transferred into the finished state while any in-progress files are rolled back, so that they do not contain data that arrived after the checkpoint from which we restore

大致翻译

        flink 正常写 in-gress文件  当发起chckpoint的时候 in-gress文件改成pending  当checkpoint完成时  pending改成finish. 如果checkpoint成功后 还没来得及改就挂掉文件依然是pending, 当flink任务从checkpoint 起来后 会得到状态 将pending文件改成finsh  将in-gress文件给清理掉(2.7版本以后支持,)  这样就保证了一致性