1.Flink容错机制的核心是检查点获取分布式数据流和操作者状态的一致性快照。恢复Flink作业时，这些快照作为一致性检查点存在。 1.1原理1.1.1 BarriersBarrier由流源注入数据流，作为数据流的一部分与数据记录一起向下游流动。 Barriers将流中的记录分成记录集片段，每个记录集对应一个快照。 每个栅栏将携带快照的ID，该ID对应于栅栏前面的记录集。 如下图所示 当一个操作符从所有输入流接收到一个屏障的快照(n)时，它将首先生成该操作符的状态快照，然后向该操作符的所有下游广播一个屏障。 当这个操作符是sink操作符时，它会通知检查点的协调器(通常是flink的jobManager)，当所有sink操作符通知barrier已经接收到快照时，就会生成快照。 1.1.2对齐的检查点当操作员接收到一个以上的输入流时，有必要对这些流进行屏障对齐。 当一个操作符接收到第一个输入流的快照屏障n时，它不能继续求解该流的其余数据。相反，它需要等到接收到最后一个流屏障n后，才能生成操作符的状态快照并发送挂起的输出记录，然后发送快照屏障n。 否则，检查点快照n和检查点n+1将会混淆。 检查点对齐保证了状态的准确性，但由于对齐操作是阻塞的，会使检查点生成时间不可控，降低吞吐量。当工作有反压时，会加剧反压，甚至导致工作不稳定。 1.1.3未对齐的检查点为避免上述风险，从Flink 1.11开始，检查点也可以未对齐。 方法类似于Chandy-Lamport算法，但Flink仍然在数据源中插入了一个屏障，以避免检查点协调器过载。 具体求解过程如下:当操作者收到第一个数据流的barrier n时，立即开始生成快照，将barrier发送给下游，将后续快照的记录异步存储在其他流中，并创建自己的状态快照。 非对齐的检查点可以确保障碍尽快到达汇点，这非常适合于操作符拓扑中至少有一条慢速路径的场景。 但因为会增加I/O压力，所以如果写状态的后台是为了解决瓶颈，就不宜使用非对齐检查点。 1.2有许多使用配置检查点的配置。下面是一些常见且重要的配置，了解详情。 1.2.1检查点保留策略默认情况下不保留检查点，仅在作业失败时用于恢复。 当程序被取消时，检查点将被删除。 但是，您可以配置定期保留的检查点。由于这些配置，当作业失败或取消时，不会自动清理保留的检查点。 这样，当作业失败时，就有一个检查点可用于恢复。 check point config config = env . getcheckpointconfig()；config . enableexternalizedcheckpoints(externalizedcheckpointclean up。RETAIN _ ON _ CANCELLATION)；ExternalizedCheckpointCleanup配置在取消作业时是保留还是删除检查点。 外部化检查点清理。Retain _ on _ cancellation:取消作业时保留检查点。 请注意，在这种情况下，您必须在取消后手动清除检查点状态。 外部化检查点清理。Delete _ on _ cancellation:取消作业时删除检查点。 检查点状态仅在作业失败时可用。 1.2.2目录配置检查点保存的信息包括元数据文件和数据文件，可以通过配置文件进行配置，是全局的，适用于所有作业。 state . check points . dir:HDFS://check points/使用状态后台FsStateBackend或RocksDBStateBackend时，可以指定相关作业的检查点保存目录env . setstate back end(new rocksdbstate back end(" HDFS://check points-data/")；1.2.3模式配置检查点支持两种模式:恰好一次和至少一次，默认模式为恰好一次。 //将mode设置为恰好一次(这是默认值)env.getCheckpointConfig()。setCheckpointingMode(CheckpointingMode。正好_一次)；恰好一次:确保每条数据只影响Flink的状态结果一次。 至少一次:每条数据至少影响一次Flink状态的计算。 1.2.4后端选择关于后端的配置和选择，请参考前文flink的第七篇详解——状态管理1.3未对齐检查点。2.保存点是使用检查点机制创建的，它是作业执行状态的全局镜像，可用于挂起、恢复、更新等。弗林克的。 保存点由两部分组成:一部分是二进制文件保存在稳定存储中的目录(如HDFS、S3等)。)，另一个是元数据文件。 这些文件代表了作业执行状态的镜像，其中元数据文件主要保存由绝对路径表示的指针。 保存点文件保存在默认目录配置中# defaultsavepointtargetdirectory state . save points . dir:HDFS://Flink/save point 1.1使用#触发保存点$ bin/Flink save point:jobid[:target directory]#删除保存点$ bin/Flink cancel-s[:target directory]:jobid # restore $ bin/Flink run-s:save path[:runargs]#删除保存点$ bin/Flink save point-d:save path 1.2配置操作员id。使用保存点进行恢复时，保存点中操作符状态的存储位置根据操作符ID进行匹配。 官方文档强烈建议为每个操作员手动配置一个操作员ID，可以通过uid(String)方法进行配置。 当没有手动配置时，程序将根据操作员在程序操作员拓扑中的位置生成一个ID。 如果程序没有变化，可以从保存点恢复，但是如果程序发生变化，同一个操作符在程序中的位置也会发生变化，对应的操作符ID也会发生变化，所以不能从前一个保存点恢复。 数据流& lt字符串& gtstream = env。//ID为的有状态源(如Kafka)。addSource(new StatefulSource())。uid("source-id") //源操作员的id。shuffle()//ID为的状态映射器。map(new StatefulMapper())。uid("mapper-id") //映射器的ID//无状态打印接收器。print()；//自动生成的ID因为有些操作符是有状态的，有些是无状态的，其实只需要给有状态的操作符加上操作符ID就可以了，但是很多人不知道哪些操作符是有状态的，哪些是无状态的。因此，在实践中，请尝试为每个操作员手动配置操作员ID。 三。检查点和保存点之间的相似性和差异3.1相似性都用于作业恢复。它们在创建时都使用相同的代码和数据格式。3.2区别在于设计目的不同:检查点是作为Flink作业的容错机制而存在的，用于作业失败时的恢复。保存点用于保存作业需要重启时的状态(例如，Flink版本更新、作业拓扑变化、并行性修改、作业A/B测试等)。) 生命周期不同:检查点的生命周期由flink管理，负责检查点的创建、维护和发布，过程中不存在与客户的交互。 保存点不同。它由客户创建、维护和删除。保存点经过预先规划、手动备份并用于恢复。 实现是不同的:检查点作为一种恢复机制，需要周期性地触发和保存状态。 实现需要满足两点:1)创建时尽可能轻量级，2)尽可能快速恢复。 保存点在创建和恢复时比检查点更重，它更关注便利性和对上述作业更改的支持。