Flink的检查点算法

Flink的恢复机制基于应用状态的一致检查点。在有状态的流应用中,一个一致性检查点是:在所有tasks处理了一个(相同的)输入后,当前时间点每个task的state副本。

在为application做一个一致性检查点时,一个基本的朴素算法机制如下步骤:

  1. 暂停所有输入流的消费。
  2. 等待所有未被处理的data完全被处理,表示所有tasks已经处理了它们所有的输入数据。
  3. 做检查点:复制每个task的state到一个远端持久性存储。在所有tasks完成了它们的副本后,检查点完成。
  4. 恢复消费输入流。

实际上Flink并不是基于上述朴素检查点算法,而是基于Chandy-Lamport算法(用于做分布式快照)实现了检查点机制。此算法并不停止整个应用的运行,而是将做快照的操作从流处理解耦出来,这样一些tasks可以持续运行,而其他tasks可以持久化它们的状态。实现原理:

  1. 使用了一个特殊的record类型,称为一个检查点分界(checkpoint barrier)。检查点barriers由source operator注入到常规的流记录中,任务向下游所有分区广播该检查点分界。
  2. 任务收到上游分区的barrier后,缓存该分区barrier后的records,直到所有上游分区的barrier都收到后,向JM确认(Acknowledge),在state backend保存检查点,然后广播barrier到该任务的下游tasks。该机制称为alignment机制。
  3. 检查点 barriers 到达一个sink task。它会做一个barrier 调整(alignment),给它自己的状态做检查点,并向JM确认它已收到barrier。JobManager在收到一个application的所有task发送的checkpoint acknowledge后,它会记录:此application的检查点完成。
  4. 一个source发出的每个分区的数据是FIFO的,保证barrier无法被其他records赶超。多个source或分区的数据顺序由任务的alignment机制保证顺序。
  5. 每个检查点barrier会携带一个检查点ID,用于辨别它属于哪个检查点,并且将一个流在逻辑上分成两部分。

应用恢复到检查点状态的步骤:

  1. 重启整个application。
  2. 重置所有stateful tasks的状态为最近的检查点。
  3. 恢复所有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)。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值