文章目录
- 知识点
- 状态
- Flink容错恢复
- 周期性的 Checkpoint
- 错误检测 Failure Detected
- 重新调度 Re-scheduling
- 状态恢复 State Recovery
- 通用增量Checkpoint
知识点
状态
算子需要记录之前数据处理的中间结果，把中间结果暂时缓存在算子的内部，这就是算子的状态。
为了避免算子挂掉，状态丢失，就需要重头开始进行Flink作业，这样效率太差，为了解决算子挂掉导致状态丢失无法恢复算子、算子状态的问题，周期性的对算子状态进行snapshot，这就是Flink的CheckPoint机制
Flink容错恢复
因为Checkpoint是频发的，所以Checkpoint过程要尽可能轻量、稳定且能够保证成功。
容错恢复过程有以下几个方面
周期性的 Checkpoint
错误检测 Failure Detected
如果某个节点挂了，就需要快速的发现这个失败节点，并完成相应的清理工作
重新调度 Re-scheduling
生成新的作业并重新调度，最后完成部署
状态恢复 State Recovery
作业重新调度起来以后，就需要从最新的快照中把算子的中间状态恢复起来
通用增量Checkpoint
Generic Log-based Incremental Checkpoints
算子在更新自身状态时，会将状态更新结果记录到状态表中
快照异步上传到DFS的时间和状态表的大小正相关，时间非常长并且不可控
为了解决这个问题引入了通用增量Checkpoint机制
解耦状态表和增量日志上传过程
在维护原有状态表的同时，记录一份增量状态更新日志（Change Log）
原有的算子状态快照的过程有两个部分
第一个部分是同步对算子进行快照，这个过程中内存的数据会刷写到磁盘，准备好上传到DFS的文件
第二个部分就是异步上传快照文件
存在的问题
- 异步上传的文件大小严重依赖StateBackend的实现
- 在同步快照结束前，是无法开始异步上传过程的，整个异步上传过程要等到同步过程结束后才能进行
对于第一个问题，以RocksDB为例，虽然说RocksDB支持增量快照，但是RocksDB因为自身的实现机制，需要对文件Compaction，每次Compaction都会产生新的比较大的文件，这种情况下即使是增量的Checkpoint也会时不时的使需要上传的Checkpoints文件变得比较大，如果并发比较大的情况下，上传文件时不时变大导致的问题就会很严重，因为只有等所有并发上传的文件都上传完毕，一个完整的算子状态才算是快照完成。
对于第二个问题，状态同步快照结束前无法开始异步上传过程，会导致较大的作业延迟
针对以上两个问题新的通用增量Checkpoint机制
算子状态更新时不仅会更新状态表，还会记录状态更新日志，这样的话状态表还是会周期性的刷新到DFS中，但是这个周期可以变得比较大，比如10分钟，状态表在后台慢慢的进行上传，这个过程称之为物化过程物化过程。同时这个状态更新日志也会不断的上传到远端DFS，并且在Checkpointing的时候Flush剩余的全部日志。
通过将状态快照过程和物化过程完全的独立开来，可以让异步上传的文件大小变得很稳定，同时因为状态更新是持续的，可以在快照之前就一直持续的上传、更新，所以在快照的时候实际上需要上传的数据量就会变得很小。物化过程结束后，相对应的更新日志可以被删除。
Change Log Storage ，DSTL（Durable Short-term Log）
DSTL的几个特性：
持久化
高频写
写延迟
一致性
