當在分布式系統中引入狀態時，自然也引入了一致性問題。一致性實際上是"正確性級別"的另一種說法，也就是說在成功處理故障並恢復之後得到的結果，與沒有發生任何故障時得到的結果相比，前者到底有多正確？舉例來說，假設要對最近一小時登入的使用者計數。在系統經歷故障之後，計數結果是多少？如果有偏差，是有漏掉的計數還是重複計數？
在流處理中，一致性可以分為3個級別：
曾經，at-least-once非常流行。第一代流處理器(如storm和samza)剛問世時只保證at-least-once，原因有二:
最先保證exactly-once的系統(storm trident和spark streaming)在效能和表現力這兩個方面付出了很大的代價。為了保證exactly-once，這些系統無法單獨地對每條記錄運用應用邏輯，而是同時處理多條(一批)記錄，保證對每一批的處理要麼全部成功，要麼全部失敗。這就導致在得到結果前，必須等待一批記錄處理結束。因此，使用者經常不得不使用兩個流處理框架(乙個用來保證exactly-once，另乙個用來對每個元素做低延遲處理)，結果使基礎設施更加複雜。曾經，使用者不得不在保證exactly-once與獲得低延遲和效率之間權衡利弊。flink避免了這種權衡。
flink的乙個重大價值在於，它既保證了exactly-once，也具有低延遲和高吞吐的處理能力
從根本上說，flink通過使自身滿足所有需求來避免權衡，它是業界的一次意義重大的技術飛躍。儘管這在外行看來很神奇，但是一旦了解，就會恍然大悟。
目前我們看到的一致性保證都是由流處理器實現的，也就是說都是在 flink 流處理器內部保證的；而在真實應用中，流處理應用除了流處理器以外還包含了資料來源（例如 kafka）和輸出到持久化系統。
端到端的一致性保證，意味著結果的正確性貫穿了整個流處理應用的始終；每乙個元件都保證了它自己的一致性，整個端到端的一致性級別取決於所有元件中一致性最弱的元件。
具體可以劃分如下：
（1）冪等寫入
所謂冪等操作，就是乙個操作，可以重複執行很多次，但只導致一次結果更改，也就是後面再重複執行不起作用了
（2）事務寫入
需要構建事務來寫入外部系統，構建的事務對應著checkpoint，等到checkpoint真在完成的時候，才能把所有對應的結果寫入sink系統中
對於事務性寫入，具體又有兩種實現方式 ：
datastream api 提供了genericwriteaheadsink模板類和twophasecommitsinkfunction介面，可以方便的實現這兩種方式的事務性寫入
不同 source 和 sink 的一致性保證可以用下表說明 ：
flink 狀態一致性（十三）
狀態一致性1.有狀態的流處理，內部每個運算元任務都可以有自己的狀態 2.對於流處理內部來說，所謂的狀態一致性就是我們所說的計算結果要保證準確 3.一條資料不丟失，也不重複計算 4.在遇到故障時可以恢復狀態，恢復以後的重新計算，結果應該也是完成正確的狀態一致性分類 1.exactly once 恰好處...
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
flink 保證一致性的 barrier對 齊
barrier對 齊 1.什麼是barrier對 齊？旦operator從輸 入流接收到checkpoint barrier n，它就不能處理 來 該流的任何資料記錄，直到它從其他所有輸入接收到barrier n為止。否則，它會混合屬於快照n的記錄和屬於快照n 1的記錄接收到barrier n的流暫...