一队魏、歷史變遷
- 在Flink 1.0.0時期
提供了RocksDB的支持万搔，這個版本之前所有的狀態(tài)都只能存在進程的內存里面，這個內存總有存不下的一天瞬雹，如果存不下則會發(fā)生OOM。如果想要存更多數據酗捌、更大量State就要用到RocksDB。RocksDB是一款基于文件的嵌入式數據庫意敛，它會把數據存到磁盤，但是同時它又提供高效讀寫能力草姻。所以使用RocksDB不會發(fā)生OOM這種事情。
在Flink1.1.0里面撩独，提供了純異步化的RocksDB的snapshot。以前版本在做RocksDB的snapshot時它會同步阻塞主數據流的處理澳迫，很影響吞吐量，即每當checkpoint時主數據流就會卡住橄登。純異步化處理之后不會卡住數據流，于是吞吐量也得到了提升拢锹。
- 在Flink 1.3.0時期: 增量checkpoint
引入了增量的checkpoint這個比較重要的功能。只有基于增量的checkpoint才能更好地支持含有超大State的Job卒稳。如果每一次都把全量上TB的State都刷到遠程的HDFS上那么這個效率是很低下的。而增量checkpoint只是把checkpoint間隔新增的那些狀態(tài)發(fā)到遠程做存儲充坑，每一次checkpoint發(fā)的數據就少了很多，效率得到提高捻爷。在這個版本里面還引入了一個細粒度的recovery，細粒度的recovery在做恢復的時候役衡，有時不需要對整個Job做恢復薪棒，可能只需要恢復這個Job中的某一個子圖，這樣便能夠提高恢復效率俐芯。
- 在Flink 1.5.0時期：Local Recovery
引入了Task local 的State的recovery。因為基于checkpoint機制吧史，會把State持久化地存儲到某一個遠程存儲，比如HDFS贸营，當發(fā)生Failover的時候需要重新把這個數據從遠程HDFS再download下來，如果這個狀態(tài)特別大那么該download操作的過程就會很漫長钞脂，導致Failover恢復所花的時間會很長。Task local state recovery提供的機制是當Job發(fā)生Failover之后冰啃，能夠保證該Job狀態(tài)在本地不會丟失，進行恢復時只需在本地直接恢復阎毅，不需從遠程HDFS重新把狀態(tài)download下來，于是就提升了Failover recovery的效率扇调。
二、Asynchronous State Snapshots
我們注意到上面描述的機制意味著當 operator 向后端存儲快照時痴腌，會停止處理輸入的數據。這種同步操作會在每次快照創(chuàng)建時引入延遲士聪。
我們完全可以在存儲快照時，讓 operator 繼續(xù)處理數據剥悟，讓快照存儲在后臺異步運行。為了做到這一點区岗，operator 必須能夠生成一個后續(xù)修改不影響之前狀態(tài)的狀態(tài)對象。例如 RocksDB 中使用的寫時復制（ copy-on-write ）類型的數據結構慈缔。
接收到輸入的 barrier 時，operator異步快照復制出的狀態(tài)(注：checkpoint的同步部分藐鹤，復制狀態(tài)可能會花費較多的時間，這也是為什么checkpoint同步部分時間很長的原因)娱节。然后立即發(fā)射 barrier 到輸出流，繼續(xù)正常的流處理肄满。一旦后臺異步快照完成，它就會向 checkpoint coordinator（JobManager）確認 checkpoint 完成〕砬福現在 checkpoint 完成的充分條件是：所有 sink 接收到了 barrier，所有有狀態(tài) operator 都確認完成了狀態(tài)備份（可能會比 sink 接收到 barrier 晚）怒炸。
RocksDBStateBackend 模式對于較大的 Key 進行更新操作時序列化和反序列化耗時很多【琅冢可以考慮使用 FsStateBackend 模式替代。
三恢口、理解Checkpoint
heavy alignments
如何選用合適的狀態(tài)后端
