狀態一致性
1.有狀態的流處理，內部每個運算元任務都可以有自己的狀態
2.對於流處理內部來說，所謂的狀態一致性就是我們所說的計算結果要保證準確
3.一條資料不丟失，也不重複計算
4.在遇到故障時可以恢復狀態，恢復以後的重新計算，結果應該也是完成正確的
1.exactly-once
恰好處理一次是最嚴格的保證，也是最難實現的。恰好處理一次語義不僅僅意味著沒有事件的丟失，還意味著針對每乙個資料，內部狀態僅僅更新一次
2.at-most-once
最多處理一次事件。當任務故障時，最簡單的做法是什麼都不做，既不恢復丟失的狀態，也不重複丟失的資料。
3.at-least-once
至少一次語義
在大多數的真實應用場景中，我們希望不丟失事件，但是會處理多次
1.flink使用了一種輕量級快照機制--檢查點機制（checkpoint）來保證exactly-once語義
2.有狀態流應用的一致檢查點，其實就是：所有任務的狀態，在某個時間點的乙份拷貝，而這個時間點，應該是所有任務都恰好處理完乙個相同的輸入資料的時候
3.應用狀態的一致檢查點，是fink故障恢復機制的核心
1.目前一致性都是在flink流處理器中實現的，也就是說在flink流處理內部能夠保證一致性。但是流處理應用還包括資料來源和輸出到持久化系統中
2.端到端的一致性保證，意味著結果的正確性貫穿了整個流處理應用的始終，每乙個元件都保證了他自己的一致性
3.end-to-end的一致性級別處決於所有元件中最弱的元件（木桶效應）
end-to-end的exactly-once保證
1、內部保證：checkpoint
2.source端：可重設資料的讀取位置
3.sink端：從故障恢復時，資料不會重複寫入到外部系統
利用下面操作保證不會重複：
--冪等性寫入
--事務寫入
--冪等性
就是乙個操作，可以重複執行很多次，但是只導致一次結果的更改，就是只持久化一次，後面的重複執行不起作用
--事務寫入
事務：1.應用程式中一系列嚴密的操作，所有操作必須完成，否自所有的操作撤銷
2.具有原子性，乙個操作要麼全部完成要麼全部失敗
實現：構建的事務對應著checkpoint，等到checkpoint真正完成的時候，才把所有對應的結果寫入sink系統中。
方式：1.預寫日誌（wal）
2.兩個階段提交
--- wal：
1.吧結果資料先當成狀態儲存，然後在收到checkpoint完成的通知時，一次性寫入 sink系統
2.簡單易於實現，由於資料提前在狀態後端中做了快取，所以無論什麼sink系統，都能 用這種方式完成
3.datastreamapi提供乙個模板類：genericwriteaheadsink，來實現這種事務性 sink
--- 兩階段提交（two-phase-commit）2pc：
1.對於每個checkpoint，sink事務會啟動乙個事務，並將接下來所有的接受的資料添 加到事務裡
2.然後將這些資料寫入外部sink系統，但不提交他們，預提交
3.當她收到checkpoint完成的通知時，才正式提交事務，實現結果的真正寫入
4.這種方式真正實現了exactly--once，他需要乙個提供事務支援的外部sink 系 統。flink提供了twophasecommitsinfunction介面
2pc對外部系統的要求：
1.外部sink系統必須提供事務支援，或者sink任務必須能夠模擬外部系統上的事務
2.在checkpoint的間隔期間裡，必須能夠開啟乙個事務並結構資料寫入
3.在收到checkpoint完成的通知之前，事務必須是等待提交的狀態，在故障恢復的情況寫，這可能需要一些是時間。如果這個時候sink系統關閉事務（例如超時了），那麼未提交的資料就會丟失
4.sink任務必須能夠在程序失敗後恢復事務
5.提交事務必須是冪等性
1.內部--利用checkpoint機制，吧狀態存檔，發生故障時可以恢復，保證內部狀態的一致性
2.source--kafka consumer作為source，可以將偏移量儲存下來，如果後續任務出現了故障，恢復的時候可以由聯結器重置偏移量，重新消費資料，保證了一致性
3.sink--kafka producer作為sink，採用兩階段提交sink，需要實現乙個twophasecommitsinkfunction介面
kafka作為外部系統的2pc情況：
---exactly-once的兩階段提交
1.jobmanager協調各個taskmanager進行checkpoint儲存
2.checkpoint儲存在statebackend中，預設statebackend是記憶體級的，也可以改為檔案級的進行持久化儲存
3.當checkpoint啟東時，jobmanager會將檢查點分界線（barrier）注入資料流中，
4.barrier會在運算元間傳遞下去
5.每個運算元會對當前的狀態做個快照，儲存到狀態後端
6.checkpoint機制可以保證內部的狀態一致性
7.每個內部的transform任務遇到barrier時，都會把狀態存到checkpoint裡
8.sink任務首先把資料寫入到外部kafka，這些資料都屬於預提交的事務，遇到barrier時，把狀態儲存到狀態後端，並開啟新的預提交事務
9.當所有運算元任務的快照完成，也就是這次的checkpoint完成時，jobmanager會向所有任務傳送通知，確認這次checkpoint完成
10.sink任務收到確認通知，正式提交之前的事務，kafka中未確認資料改為「已確認」
步驟：1.第一條資料來了之後，開啟乙個kafka事務，正常寫入kafka分割槽日誌單標記為未提交，這就是預提交。。
2.jobmanager出發checkpoint操作，barrier從source開始向下傳遞，遇到barrier的運算元將狀態存入狀態後端，並通知jobmanager
3.sink聯結器收到barrier，儲存當前狀態，存入checkpoint，通知jobmanager,並開啟下一階段的事務，用於提交下個檢查點的資料
4.jobmanager收到所有任務的通知，發出確認資訊，表示checkpoint完成
5.sink任務收到jobmanager的確認資訊，正式提交這段時間的叔叔
6.外部kafka關閉事務，提交的資料可以正常消費了
Flink 狀態一致性
當在分布式系統中引入狀態時，自然也引入了一致性問題。一致性實際上是 正確性級別 的另一種說法，也就是說在成功處理故障並恢復之後得到的結果，與沒有發生任何故障時得到的結果相比，前者到底有多正確？舉例來說，假設要對最近一小時登入的使用者計數。在系統經歷故障之後，計數結果是多少？如果有偏差，是有漏掉的計數...
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
flink 保證一致性的 barrier對 齊
barrier對 齊 1.什麼是barrier對 齊？旦operator從輸 入流接收到checkpoint barrier n，它就不能處理 來 該流的任何資料記錄，直到它從其他所有輸入接收到barrier n為止。否則，它會混合屬於快照n的記錄和屬於快照n 1的記錄接收到barrier n的流暫...