Flink狀態後端和CheckPoint機制

6.8.5 狀態後端

什麼是狀態後端？

每傳入一條資料，有狀態的運算元任務都會讀取和更新狀態。狀態的儲存、訪問以及維護，由乙個可插入的元件決定，這個元件就是狀態後端。

狀態後端的作用？

本地的狀態管理

將檢查點（checkpoint）狀態寫入遠端儲存

①memorystatebackend

記憶體級別的狀態後端

**特點：**速度快、延遲低、不穩定

②fsstatebackend

**特點：**速度快、容錯性好

**使用場景：**1常規使用狀態的作業、2需要開啟ha的作業、3可以在生產環境使用

③rocksdbstatebackend

什麼是rocksdb？

將所有的狀態序列化後，存入本地的rocksdb資料庫中，一種nosql資料庫，kv形式儲存。

**使用場景：**1超大狀態的作業、2需要開啟ha的作業、3對讀寫效能要求不高的作業、4可以在生產環境使用

（2）配置狀態後端

①全域性配置狀態後端

在flink-conf.yaml檔案中設定預設的全域性後端

②在**中配置狀態後端

匯入rocksdbstatebackend的依賴

>

>
org.apache.flinkgroupid
>
>
flink-statebackend-rocksdb_$artifactid
>
>
$version
>
>
providedscope
>
dependency
>

public

class
flink30_state_backend
}

什麼是狀態的一致性？

狀態的一致性是當發生故障的時候，資料恢復的正確程度，是丟失資料了還是資料重**送了？

① at-most-once（最多一次性）

資料有可能丟失

資料有可能發生重複，但是一定不會丟失資料

資料不多不少

雖然很多框架都能保證框架內部能夠一致性，但是流處理應用還應該能夠保證從資料來源(kafka) - flink - 持久化系統(db)的一致性。整個端到端的一致性級別，取決於所有元件中一致性最弱的元件

需要外部源能夠根據讀取位置重設偏移量，比如kafkasource，讀取資料的時候可以執行offset

flink內部依賴於（狀態後端）checkpoint機制，保證狀態一致性

flink是如何保證exactly-once的呢？ --檢查點checkpoint機制，在出現故障時系統重置回正確狀態。

flink的barrier是什麼？它是怎樣生成的？

barrier籬笆，柵欄，也就是特殊資料

流的barrier是flink的checkpoint中的乙個核心概念，多個barrier被插入到資料流中，作為流的一部分，隨著資料流動（類似於watermark）。這些barrier不會跨越流中的資料。

barrier把資料分成兩個部分，一部分進入當前的快照，另一部分資料進入下乙個快照。

每個barrier都攜帶著快照的id，barrier不會暫停資料的流動

flink執行過程中掛掉了，資料如何恢復呢？

以最近完整的一次備份進行恢復

flink預設只儲存乙個最新的一次完整備份，其他的都會刪掉。

state.checkpoints.num-retained

1integer

the maximum number of completed checkpoints to retain.

要保留的已完成檢查點的最大數目

多並行度下，如果要實現精準一次，要執行barrier對齊。

Flink狀態後端

memorystatebackend public memorystatebackend val env streamexecutionenvironment streamexecutionenvironment.getexecutionenvironment 配置使用memorystateback...

Flink的狀態管理與狀態後端

flink是乙個基於狀態計算的流計算服務。flink將所有的狀態分為兩大類 keyed state 與 operator state 所謂的keyed state指的是flink底層會給每乙個key繫結若干個型別的狀態值，特指操作 keyedstream中所涉及的狀態。所謂operator stat...

Flink 狀態管理

有些任務的結果不僅僅依賴於當前的輸入，也依賴於之前的輸入結果資訊，因此對中間結果狀態等的儲存就很有必要。在flink中，我們可以這樣理解state 某task operator在某時刻的乙個中間結果。flink提供了豐富的狀態訪問介面和高效的容錯機制，當前flink中有兩個基本的state keye...