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