Flink容错机制

• 在分布式架构中，当某个节点出现故障， 其他节点基本不受影响。这时只需要重启应用， 恢复之前某个时间点的状态继续处理就可以了，在实时流处理中，不仅需要保证故障后能够重启继续运行， 还要保证结果的正确性、故障恢复的速度、对处理性能的影响， 这就需要在架构上做出更加精巧的设计。在 Flink 中，有一套完整的容错机制(fault tolerance)来保证故障后的恢复， 其中最重要的就是检查点(checkpoint)。
  
   
• 检查点：

  发生故障之后怎么办？最简单的想法当然是重启机器、重启应用。这里的问题在于， 流处理应用中的任务都是有状态的， 而为了快速访问这些状态一般会直接放在堆内存里；重启应用内存中的状态已经丢失。为了不浪费之前的计算 所以需要把之前的计算结果做个保存，这样重启之后就可以继续处理新数据、而不需要重新计算了。就是将之前某个时间点所有的状态保存下来， 这份“存档”就是所谓的“检查点” (checkpoint)。 遇到故障重启的时候，我们可以从检查点中恢复出之前的状态，这样就可以回到保存时的数据接着处理了。
  检查点是 Flink 容错机制的核心。故障恢复之后继续处理的结果， 应该与发生故障前完全一致所以，有时又会把 checkpoint 叫作“一致性检查点”。
  
   1）检查点的保存：
      周期性的触发保存：
     “随时存档”确实恢复起来方便， 可是需要不停地做存档操作。如果每处理一条数据就进行检查点的保存，当大量数据同时到来时，就会耗费很多资源来频繁做检查点，数据处理的速度就会受到影响。所以更好的方式是，每隔一段时间去做一次存档，这样既不会影响数据的正常处理，也不会有太大的延迟毕竟故障恢复的情况不是随时发生的。在 Flink 中，检 查点的保存是周期性触发的，间隔时间可以进行设置。
  这里有一个关键问题：当检查点的保存被触发时， 任务有可能正在处理某个数据，这时该怎么办呢？最简单的办法是，可以在某个时刻让所有任务停止处理数据。这样状态就不再更改，可以一起复制保存；保存完之后再恢复数据处理就可以了。然而会发现有很多问题。这种想法其实是粗暴地中断任务来做检查点保存，这会造成很大的延迟。另一方面， 做快照的目的是为了故障恢复；现在的快照中，有些任务正在处理数据，那它保存的到底是处理到什么程度的状态呢？ 假如在程序中某一步操作中自定义了一个ValueState，处理的逻辑是当遇到一个数据时，状态先加 1；而后经过一些其他步骤后再加 1。现在停止处理数据， 状态到底是被加了 1 还是加了 2 呢？
  而且在分布式系统的节点之间需要通过网络通信来传递数据，如果我们保 存检查点的时候刚好有数据在网络传输的路上，那么下游任务是没法将数据保存起来的；故障重启之后，我们只能期待上游任务重新发送这个数据。然而上游任务是无法知道下游任务是否 收到数据的，只能盲目地重发， 这可能导致下游将数据处理两次， 结果就会出现错误。
  所以最终的选择是： 当所有任务都恰好处理完一个相同的输入数据的时候，将它们的状态保存下来。首先，这样避免了除状态之外其他额外信息的存储，提高了检查点保存的效率。 其次， 一个数据要么就是被所有任务完整地处理完，状态得到了保存； 要么就是没处理完， 状态全部没保存：这就相当于构建了一个“事务”(transaction)。如果出现故障，我们恢复到之前保存的状态， 故障时正在处理的所有数据都需要重新处理； 所以我们只需要让源(source) 任务向数据源重新提交偏移量、请求重放数据就可以了。
  
  当需要保存检查点（checkpoint）时，就是在所有任务处理完同一条数据后，对状态 做个快照保存下来。例如上图中，已经处理了 3 条数据：“hello”“world”“hello”，所以我们会看到Source 算子的偏移量为 3；后面的 Sum 算子处理完第三条数据“hello”之后，此时已经有 2 个“hello”和 1 个“world”，所以对应的状态为“hello”-> 2，“world”-> 1（这里 KeyedState底层会以 key-value 形式存储&#x