Flink状态一致性笔记

时间:2021-01-12
本文章向大家介绍Flink状态一致性笔记,主要包括Flink状态一致性笔记使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

知识点

状态一致性分类:
    • AT-MOST-ONCE(最多一次):当任务故障时,最简单的做法是什么都不干,既不恢复丢失的状态,也不重播丢失的数据。At-most-once 语义的含义是最多处理一次事件。 
    • AT-LEAST-ONCE(至少一次):在大多数的真实应用场景,我们希望不丢失事件。这种类型的保障称为 at- least-once,意思是所有的事件都得到了处理,而一些事件还可能被处理多次。 
    • EXACTLY-ONCE(精确一次):恰好处理一次是最严格的保证,也是最难实现的。恰好处理一次语义不仅仅 意味着没有事件丢失,还意味着针对每一个数据,内部状态仅仅更新一次

EXACTLY-ONCE(精确一次):通过checkpoint(快照)机制来保证


端到端(end-to-end)状态一致性 
    • 目前我们看到的一致性保证都是由流处理器实现的,也就是说都是在 Flink 流处理器内部保证的;而在真实应用中,流处理应用除了流处理 器以外还包含了数据源(例如 Kafka)和输出到持久化系统 
    • 端到端的一致性保证,意味着结果的正确性贯穿了整个流处理应用的 始终;每一个组件都保证了它自己的一致性 
    • 整个端到端的一致性级别取决于所有组件中一致性最弱的组件
    
端到端 exactly-once 
    • 内部保证 —— checkpoint 
    • source 端 —— 可重设数据的读取位置 (kafka的offset)
    • sink 端 —— 从故障恢复时,数据不会重复写入外部系统 : 幂等写入 、事务写入(预写日志、两阶段提交)
    
幂等写入:所谓幂等操作,是说一个操作,可以重复执行很多次,但只导致一次 结果更改,也就是说,后面再重复执行就不起作用了

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

预写日志(Write-Ahead-Log,WAL) 
    • 把结果数据先当成状态保存,然后在收到 checkpoint 完成的通知时, 一次性写入 sink 系统 
    • 简单易于实现,由于数据提前在状态后端中做了缓存,所以无论什么 sink 系统,都能用这种方式一批搞定 
    • DataStream API 提供了一个模板类:GenericWriteAheadSink,来实 现这种事务性 sink
    
两阶段提交(Two-Phase-Commit,2PC) 
    • 对于每个 checkpoint,sink 任务会启动一个事务,并将接下来所有接 收的数据添加到事务里 
    • 然后将这些数据写入外部 sink 系统,但不提交它们 —— 这时只是 “预提交” 
    • 当它收到 checkpoint 完成的通知时,它才正式提交事务,实现结果 的真正写入 ; 这种方式真正实现了 exactly-once,它需要一个提供事务支持的外部 sink 系统。Flink 提供了 TwoPhaseCommitSinkFunction 接口
    
    要求:
        • 外部 sink 系统必须提供事务支持,或者 sink 任务必须能够模拟外部系统 上的事务 
        • 在 checkpoint 的间隔期间里,必须能够开启一个事务并接受数据写入 
        • 在收到 checkpoint 完成的通知之前,事务必须是“等待提交”的状态。在 故障恢复的情况下,这可能需要一些时间。如果这个时候sink系统关闭 事务(例如超时了),那么未提交的数据就会丢失 
        • sink 任务必须能够在进程失败后恢复事务 • 提交事务必须是幂等操作
        
        
Flink+Kafka 端到端状态一致性的保证 
    • 内部 —— 利用 checkpoint 机制,把状态存盘,发生故障的时候可以恢 复,保证内部的状态一致性 
    • source —— kafka consumer 作为 source,可以将偏移量保存下来,如 果后续任务出现了故障,恢复的时候可以由连接器重置偏移量,重新消 费数据,保证一致性 • sink —— kafka producer 作为sink,采用两阶段提交 sink,需要实现一 个 TwoPhaseCommitSinkFunction