为什么做网站要用谷歌浏览器,盐城市网站,做视频图片博客网站有哪些,学网络营销去哪个学校Flink的恢复机制基于应用状态的一致检查点。在有状态的流应用中#xff0c;一个一致性检查点是#xff1a;在所有tasks处理了一个#xff08;相同的#xff09;输入后#xff0c;当前时间点每个task的state副本。 在为application做一个一致性检查点时#xff0c;一个基…Flink的恢复机制基于应用状态的一致检查点。在有状态的流应用中一个一致性检查点是在所有tasks处理了一个相同的输入后当前时间点每个task的state副本。 在为application做一个一致性检查点时一个基本的朴素算法机制如下步骤 暂停所有输入流的消费。等待所有未被处理的data完全被处理表示所有tasks已经处理了它们所有的输入数据。做检查点复制每个task的state到一个远端持久性存储。在所有tasks完成了它们的副本后检查点完成。恢复消费输入流。 实际上Flink并不是基于上述朴素检查点算法而是基于Chandy-Lamport算法用于做分布式快照实现了检查点机制。此算法并不停止整个应用的运行而是将做快照的操作从流处理解耦出来这样一些tasks可以持续运行而其他tasks可以持久化它们的状态。实现原理 使用了一个特殊的record类型称为一个检查点分界checkpoint barrier。检查点barriers由source operator注入到常规的流记录中任务向下游所有分区广播该检查点分界。任务收到上游分区的barrier后缓存该分区barrier后的records直到所有上游分区的barrier都收到后向JM确认Acknowledge在state backend保存检查点然后广播barrier到该任务的下游tasks。该机制称为alignment机制。检查点 barriers 到达一个sink task。它会做一个barrier 调整alignment给它自己的状态做检查点并向JM确认它已收到barrier。JobManager在收到一个application的所有task发送的checkpoint acknowledge后它会记录此application的检查点完成。一个source发出的每个分区的数据是FIFO的保证barrier无法被其他records赶超。多个source或分区的数据顺序由任务的alignment机制保证顺序。每个检查点barrier会携带一个检查点ID用于辨别它属于哪个检查点并且将一个流在逻辑上分成两部分。 应用恢复到检查点状态的步骤 重启整个application。重置所有stateful tasks的状态为最近的检查点。恢复所有tasks的处理。 数据源是否支持重置取决于它的实现CDC连接器以及流被消费的源头。例如Kafka可以提供一个流中当前偏移量之前的records从socket消费的则无法被重置因为sockets在消费完一个数据后会将它丢弃。因此一个application在仅当所有输入流是由可重置的 data sources 消费时它才能够以 exactly-once state 一致性的方式运行。 Flink的检查点与恢复机制仅重置一个流应用的internal state。在恢复时取决于应用的sink operator的不同一些records可能会多次释放给下游的流例如一个event log一个文件系统或是一个数据库。对于某些存储系统Flink的sink 函数可以提供 exactly-once 输出例如在检查点完成时才提交释放的records。另一个适用于大部分存储系统的方法是幂等更新idempotent updates。