Flink 容错机制与状态

 

简介

• Apache Flink提供了一种容错机制，可以持续恢复数据流应用程序的状态。
• 该机制确保即使出现故障，经过恢复，程序的状态也会回到以前的状态。
• Flink 主持 at least once 语义 和 exactly once 语义
• Flink 通过定期地做 checkpoint 来实现容错 和 恢复, 容错机制不断地生成数据流的快照, 而不会对性能产生太大的影响。
• 流应用程序的状态存储在一个可配置的地方(例如主节点或HDFS)
• 如果出现车程序故障(由于机器、网络或软件故障), Flink 将停止分布式流数据流。
• 然后系统重新启动 operator, 并将其设置为最近一批的检查点。
• 注意点:
  • 默认情况下, 禁用checkpoint
  • 要使得容错机制正常运行, 数据流 source 需要能够将流倒回到指定的之前的点。
  • 比如 Apache Kafka 有这种方法, flink与 Kafka 的 connector 可以利用重置 kafka topic 的偏移量来达到数据重新读取的目的。
  • 由于 Flink 的检查点由分布快照实现, 以下的"检查点" 和 "快照" 是同意义的。

CheckPoint(检查点)

• Flink 的容错机制的核心部分是生成分布式数据流和operator状态一致的快照。
• 这些快照充当检查点, 系统可以早发生故障时将其回滚。
• 分布式快照是由 Chandy-Lamport 算法实现的。
• Barriers(栅栏)

恢复

• Flink 恢复时的机制是十分直接的: 在系统失效时, Flink选择最近的已完成的检查点k, 系统接下来重新部署整个数据流图, 然后给每个Operator 在检查点 k 时的相应状态。
• 数据源则被设置为从数据流的 Sk 位置开始读取。
• 例如, 在 Apache Kafka 执行恢复时, 系统会通知消费者从便宜 Sk 开始获取数据。

先决条件

• Flink 的 checkpoint机制一般来说, 它需要:
  • 持续的数据源
    • 比如消息队列(Apache Kafka, RabbitMQ) 或文件系统(例如, HDFS, Amazon S3, GFS, NFS, Ceph ......)。
  • 状态存储的持久化
    • 通常是分布式文件系统(HDFS, Amazon S3, GFS, ...)

启用和配置检查点

• 默认情况下, flink禁用检查点。

• 开启 checkpoint 的方式: 调用env.enableCheckpointing(n), 其中 N 是以毫秒为单位的检查点间隔。

• Checkpoint 的相关参数:

State Backends(状态反压)

• 流计算中再以下场景中需要保存状态:

  • 窗口操作
  • 使用了 KV 操作的函数
  • 继承了 CheckpointFunction 的函数

• 当检查点(checkpoint) 机制启动时, 状态将在检查点中持久化来应对数据丢失以及恢复。

• 而状态在内部是如何表示的、状态是如何持久化到检查点中以及持久化到哪里都取决于选定的 State Backend。

• Flink 在保存状态时, 支持3中存储方式:

  • MemoryStateBackend(内存状态反压)
  • FsStateBackend(文件状态反压)
  • RocksDBStateBackend(RocksDB状态反压)

• 如果没有配置其他任何内容, 系统默认将使用 MemoryStateBackend。

• MemoryStateBackend

  • 此种存储策略将数据保存在java的堆里，比如：kv的状态或者窗口操作用h