狀態一致性

狀態

flink中經過狀態來實現容錯、狀態一致性以及checkpoint機制，

對於狀態通俗來說就是將數據或者程序運算的中間結果進行備份，這樣能夠保證程序中途出錯能夠從這裏恢復；

狀態類型

程序中保存的狀態保存的具體類型是什麼，哪些狀態能夠保存呢？

狀態後端

狀態後端指的是咱們將要備份的數據存在那個地方，flink中有三個方式來保存狀態，默認是保存在內存當中

1. 內存中: memoryStateBackend
2. RockDBStateBackend,將狀態存儲在本地的RockDB數據庫中，實際就是一種內存和磁盤的混合使用;
3. FsStateBackend，本地狀態保存在taskmanager中，在使用checkpoint時候就是將其存入文件系統中

checkpoint

checkpoint保證了flink的可靠性，由於它也實現了數據的一致性，實際就是按期的程序各個執行狀態進行保存，出錯後能夠實現恢復；

檢查點工做機制

checkpoint的運行工做機制就是:

JobManager內部有一個協調器，在週期型的生成barrier，從最開始的數據源開始插入，隨着數據流向後廣播傳遞；

當這個barrier到了一個task時，至關於一個開關，開啓當前task的備份；一般一個task中會對應上游多個task向他傳遞數據流，那這個task會等到全部的上游task到齊以後在觸發備份機制，

固然這其中會涉及barrier對齊的特性，就是當某一個上游task中的barrier先到了，那麼這個barrier以後的數據會等待，知道全部的上游task中全部的barrier都到齊之後開始checkpoint纔開始計算，這樣就能夠保證數據的一致性，精準一次消費；

當這個task完成備份之後會向jobmanager裏的協調器發一個消息，通知到此次保存的checkpoint的地址和相關的元數據；

當數據處理的最後完成checkpoint，在jobmanager收到後就會通知本次全局的checkpoint完成，同時它會備份之際的元數據；

固然在sink的時候會涉及二階段提交（2pc），就是一開始先預提交，收到jobmanager的 完成通知，會進行正式提交，這樣來保證精準一次消費；

checkpoint算法

chandy-lamport算法，異步分界線快照算法，這個算法能夠實現不中止流的處理，同時進行checkpoint備份；

數據一致性

數據一致性級別：

**at-most-once(_最多一次):_

這實際上是沒有正確性保障的委婉說法——故障發生以後，計數結果可能丟失

at-least-once(至少一次):

這表示計數結果可能大於正確值，但毫不會小於正確值。也就是說，計數程序在發生故障後可能多算，可是毫不會少算；

exactly-once(嚴格一次):

這指的是系統保證在發生故障後獲得的計數結果與正確值一致.既很少算也很多算

端到端一致性

source端

須要外部源可重設數據的讀取位置.目前咱們使用的Kafka Source具備這種特性: 讀取數據的時候能夠指定offset

flink內部

依賴checkpoint機制

sink端

須要保證從故障恢復時，數據不會重複寫入外部系統. 有2種實現形式:

a) 冪等（Idempotent）寫入

所謂冪等操做，是說一個操做，能夠重複執行不少次，但只致使一次結果更改，也就是說，後面再重複執行就不起做用了。

b）事務性（Transactional）寫入

須要構建事務來寫入外部系統，構建的事務對應着 checkpoint，等到 checkpoint 真正完成的時候，才把全部對應的結果寫入 sink 系統中。對於事務性寫入，具體又有兩種實現方式：預寫日誌（WAL）和兩階段提交（2PC）