為了解決系統故障之後我們無法確定資料準確性的問題，我們引入了狀態一致性的概念。
狀態一致性可以分為三種級別，分別是：
其實，flink並不是首先實現exactly-once的架構。在它之前spark-streaming已經實現了exactly-once，但是，代價是巨大的。spark-streaming為了實現exactly-once而不能對每一條資料進行處理，只能通過批處理的方式，一批資料要麼全部成功要麼全部失敗。這樣做就犧牲掉了部分的效能優勢。
flink非常大的優勢之一就是它即實現了exactly-once，又保證了低延遲和高吞吐量。
flink實現狀態一致性的原理其實很容易理解，我們可以稱它為端到端的狀態一致性。
我們可以把這個過程分成三部分：
在sink端有兩種實現方式，分別是：
flink中將事務寫入分成了兩種，分別是
flink內部是通過check point來保證exactly-once的，接下來我們來看一下check point的執行過程。
初始狀態：
儲存source位置：
儲存狀態值：
當乙個節點掛掉：
檢查點是flink最有價值的創新之一。它使flink能夠實現exactly-once並且不需要犧牲效能。
flink對kafka即支援kafka source，也支援kafka sink。我們知道flink內部是通過檢查點的方式實現exactly-once的。那麼flink與kafka之間是怎樣實現exactly-once的呢？
具體實現方式如下圖：
當檢查點執行時，jobmanager會將檢查點分界線（barrier）注入到資料流。barrier會在運算元之間傳遞。
當source檢測到barrier之後會將偏移量（offset）作為狀態儲存到狀態後端。下次從check point恢復時source會重新提交offset，從上次儲存的位置開始重新消費資料。
內部運算元檢測到barrier會將狀態提交的statebackend。
sink會先將資料寫入外部kafka，當sink檢測到barrier之後會將狀態儲存的statebackend並開啟新的預提交任務。
當所有的運算元任務完成快照，即這次檢查點完成之後，jobmanager會向所有的運算元傳送完成通知。
sink接收到通知後，會將預提交事務提交。這樣之前預提交的資料就正式確認提交了。
flink官方列舉了三種型別的狀態後端，分別是：
修改flink-conf.yarm設定預設狀態後端：
state.backend
: filesystem
state.checkpoints.dir
: hdfs://namenode:40010/flink/checkpoints
streamexecutionenvironment env = streamexecutionenvironment.
getexecutionenvironment()
;env.
setstatebackend
(new
fsstatebackend
("hdfs://namenode:40010/flink/checkpoints"))
;
Flink狀態管理和容錯機制介紹
1.1什麼是有狀態的計算 計算任務的結果不僅僅依賴於輸入，還依賴於它的當前狀態，其實大多數的計算都是有狀態的計算。比如wordcount,給一些word,其計算它的count,這是乙個很常見的業務場景。count做為輸出，在計算的過程中要不斷的把輸入累加到count上去，那麼count就是乙個sta...
Flink狀態管理和容錯機制介紹
1.1.什麼是有狀態的計算 計算任務的結果不僅僅依賴於輸入，還依賴於它的當前狀態，其實大多數的計算都是有狀態的計算。比如wordcount,給一些word,其計算它的count,這是乙個很常見的業務場景。count做為輸出，在計算的過程中要不斷的把輸入累加到count上去，那麼count就是乙個st...
Flink狀態管理和容錯機制介紹
本文主要內容如下 1.1.什麼是有狀態的計算 計算任務的結果不僅僅依賴於輸入，還依賴於它的當前狀態，其實大多數的計算都是有狀態的計算。比如wordcount,給一些word,其計算它的count,這是乙個很常見的業務場景。count做為輸出，在計算的過程中要不斷的把輸入累加到count上去，那麼co...