flink的端到端的一致性保證
狀態一致性：
有狀態的流處理，內部每個運算元都可以有自己的狀態
對於處理器內部而言，所謂的狀態一致性，其實就是我們所說的計算的結果要保證準確
一條資料都不應該丟失，也不應該重複計算同乙個資料
在遇到故障時可以恢復，恢復之後重新計算，計算的結果也應該正確不受影響
故障恢復時的三種一致性要求：
at-most-once（最多一次）
當任務故障時，最簡單的做法是什麼都不幹，既不恢復丟失的狀態，也不重播丟失的資料。at-most-once 語義的含義是最多處理一次事件。
at-least-once（至少一次）
在大多數的真實應用場景，我們希望不丟失事件。這種型別的保障稱為 at-least-once，意思是所有的事件都得到了處理，而一些事件還可能被處理多次。
exactly-once（精確一次）
恰好處理一次是最嚴格的保證，也是最難實現的。恰好處理一次語義不僅僅意味著沒有事件丟失，還意味著針對每乙個資料，內部狀態僅僅更新一次
一致性檢查點： （一致性檢查點的三種演算法：
flink 使用了一種輕量級快照機制 —— 檢查點（checkpoint）來保證 exactly-once 語義
有狀態流應用的一致檢查點，其實就是：所有任務的狀態，在某個時間點的乙份拷貝（乙份快照）。而這個時間點，應該是所有任務都恰好處理完乙個相同的輸入資料的時候。
應用狀態的一致檢查點，是 flink 故障恢復機制的核心
端到端狀態一致性，意味者正確的結果貫穿著這整個流處理應用的始終，每乙個元件都要保證他自己的一致性，整個端到端一致性級別取決於所有元件中最弱的元件
在flink中主要在於：
1.source端 - 可重設資料的讀取位置
2.內部計算處理的保證 - 檢查點的狀態一致性保證
3.sink端-從故障恢復時，資料不會重複寫入到外部的系統
1）冪等性寫入 ：可以重複執行很多次，但是只會導致一次結果的更改，後面的操作不起作用
2）事務寫入 :應用程式中一系列嚴密操作，所有操作要麼成功完成，否在每個操作都會被撤銷
具有原子性，乙個事務中的一系列操作要麼全部成功，要麼乙個都不成功
構建的事務對應上flink的checkpoint，等到checkpoint成功時才把該checkpoint對應的資料寫入到外部
事務的實現方式：
一.預寫日誌的形式
把結果資料先當成狀態儲存，然後收到checkpoint完成的通知時，一次性寫入到sink系統中
簡單易於實現，由於資料提前做了快取交給了狀態後端管理，所有物料說明sink系統都能用這種方式實現 flink提供了genericwriteaheadsink模板來實現這種事務性的sink
二.兩階段提交 2pc
對於每個 checkpoint，sink 任務會啟動乙個事務，並將接下來所有接收的資料新增到事務裡
然後將這些資料寫入外部 sink 系統，但不提交它們 —— 這時只是「預提交」）
當它收到 checkpoint 完成的通知時，它才正式提交事務，實現結果的真正寫入
這種方式真正實現了 exactly-once，它需要乙個提供事務支援的外部 sink 系統。flink 提供了 twophasecommitsinkfunction 介面。
外部 sink 系統必須提供事務支援，或者 sink 任務必須能夠模擬外部系統上的事務
在 checkpoint 的間隔期間裡，必須能夠開啟乙個事務並接受資料寫入
在收到 checkpoint 完成的通知之前，事務必須是「等待提交」的狀態。在故障恢復的情況下，這可能需要一些時間。如果這個時候sink系統關閉事務（例如超時了），那麼未提交的資料就會丟失
sink 任務必須能夠在程序失敗後恢復事務
提交事務必須是冪等操作
kafka-flink-kafka端到端狀態一致性的保證：
內部 —— 利用 checkpoint 機制，把狀態存檔，發生故障的時候可以恢復，保證內部的狀態一致性
source —— kafka consumer 作為 source，可以將偏移量儲存下來，如果後續任務出現了故障，恢復的時候可以由聯結器重置偏移量，重新消費資料，保證一致性
flink在消費kafka的資料時，在恢復狀態時並不會使用kafka自己維護的offset，假設：使用kafka自己維護的offset，當從kafka消費的資料沒有處理完時flink出現故障，flink恢復狀態從kafka維護的offset消費的話，會丟失在flink中未處理的資料，所有這樣是不合理的。
當flink故障時，flink恢復狀態時，會從上次flink 的source儲存的狀態獲取到上次消費的位置（即上次檢查點界限位置），並且從該位置消費kafka的資料
sink —— kafka producer 作為sink，採用兩階段提交 sink，需要實現乙個 twophasecommitsinkfunction
步驟：第一條資料來了之後，開啟乙個 kafka 的事務（transaction），正常寫入 kafka 分割槽日誌但標記為未提交，這就是「預提交」
jobmanager 觸發 checkpoint 操作，barrier 從 source 開始向下傳遞，遇到 barrier 的運算元將狀態存入狀態後端，並通知 jobmanager
sink 聯結器收到 barrier，儲存當前狀態，存入 checkpoint，通知 jobmanager，並開啟下一階段的事務，用於提交下個檢查點的資料
jobmanager 收到所有任務的通知，發出確認資訊，表示 checkpoint 完成
sink 任務收到 jobmanager 的確認資訊，正式提交這段時間的資料
外部kafka關閉事務，提交的資料可以正常消費了。
flink 保證一致性的 barrier對 齊
barrier對 齊 1.什麼是barrier對 齊？旦operator從輸 入流接收到checkpoint barrier n，它就不能處理 來 該流的任何資料記錄，直到它從其他所有輸入接收到barrier n為止。否則，它會混合屬於快照n的記錄和屬於快照n 1的記錄接收到barrier n的流暫...
保證一致性嗎 Kafka的一致性保證
魚和熊掌不可兼得。系統設計需要根據具體的應用場景做出權衡。系統設計者可以通過配置kafka，來得到不同程度的需求滿足。每個kafka主題 topic 都分為多個分割槽 partitions 每個分割槽可以具有多個副本 replica 其中乙個副本是主分割槽 leader 所有讀寫請求都由主分割槽提供...
Flink 狀態一致性
當在分布式系統中引入狀態時，自然也引入了一致性問題。一致性實際上是 正確性級別 的另一種說法，也就是說在成功處理故障並恢復之後得到的結果，與沒有發生任何故障時得到的結果相比，前者到底有多正確？舉例來說，假設要對最近一小時登入的使用者計數。在系統經歷故障之後，計數結果是多少？如果有偏差，是有漏掉的計數...