**
flink的恢復機制的核心就是應用狀態的一致性檢查點，有狀態流的一致性檢查點，其實就是所以狀態在某個時間點的乙份快照拷貝，而這個時間點應該是所有任務都恰好處理完同乙個輸入資料。
一般常見的檢查點演算法：
方法一：常用的某個時間點的快照
1）暫停所有輸入流的攝取有，也就是不接受性的資料輸入
2）等待所有摘出來的資料計算完畢，這就意味者結束時，所有任務都已經處理了所有的輸入資料
3）通過將每個任務的狀態複製到遠端持久儲存，來得到乙個檢查點，所有任務完成拷貝操作以後，檢查點就完成了
4）恢復所有輸入流的攝取
這種檢查點演算法就是某個時間的所有運算元任務的切片的狀態作為檢查點，這種檢查點的儲存恢復機制可以為應用程式提供精確一次的一致性，因為所有運算元都會儲存檢查點並恢復其所有的狀態，這樣所有的輸入流都會被重置到檢查點完成時的位置，至於資料來源是否可以重置它的輸入流，這取決於實現方式和消費流資料的外部介面。例如，像apache kafka這樣的事件日誌系統可以提供流上之前偏移位置的資料，所以我們可以將源重置到之前的偏移量，重新消費資料。而從套接字（socket）消費資料的流就不能被重置了，因為套接字的資料一旦被消費就會丟棄掉。因此，對於應用程式而言，只有當所有的輸入流消費的都是可重置的資料來源時，才能確保在「精確一次」的狀態一致性下執行。
方法二： 分布式非同步檢查點
方法一是先暫停應用，儲存檢查點，然後再恢復應用程式，這種方法很好理解，但它的理念是「停止一切」，這對於即使是中等延遲要求的應用程式而言也是不實用的。
所以flink沒有這麼簡單粗暴，而是基於chandy-lamport演算法實現了分布式快照的檢查點儲存。該演算法並不會暫停整個應用程式，而是將檢查點的儲存與資料處理分離，這樣就可以實現在其它任務做檢查點狀態儲存狀態時，讓某些任務繼續進行而不受影響。flink的檢查點演算法用到了一種稱為「檢查點分界線」（checkpoint barrier）的特殊資料形式。與水位線（watermark）類似，檢查點分界線由source運算元注入到常規的資料流中，它的位置是限定好的，不能超過其他資料，也不能被後面的資料超過。檢查點分界線帶有檢查點id，用來標識它所屬的檢查點；這樣，這個分界線就將一條流邏輯上分成了兩部分。分界線之前到來的資料導致的狀態更改，都會被包含在當前分界線所屬的檢查點中；而基於分界線之後的資料導致的所有更改，就會被包含在之後的檢查點中。
當source任務收到訊息時，它會暫停發出新的資料，在狀態後端觸發本地狀態的檢查點儲存，並向所有傳出的流分割槽廣播帶著檢查點id的分界線（barriers）。狀態後端在狀態檢查點完成後會通知任務，而任務會向jobmanager確認檢查點完成。在發出所有分界線後，source任務就可以繼續常規操作，發出新的資料了。通過將分界線注入到輸出流中，源函式（source function）定義了檢查點在流中所處的位置
源任務發出的檢查點分界線（barrier），將被傳遞給所連線的任務。與水位線（watermark）類似，barrier會被廣播到所有連線的並行任務，以確保每個任務從它的每個輸入流中都能接收到。當任務收到乙個新檢查點的barrier時，它會等待這個檢查點的所有輸入分割槽的barrier到達。在等待的過程中，任務並不會閒著，而是會繼續處理尚未提供barrier的流分割槽中的資料。對於那些barrier已經到達的分割槽，如果繼續有新的資料到達，它們就不會被立即處理，而是先快取起來。這個等待所有分界線到達的過程，稱為「分界線對齊」（barrier alignment）
所有的檢查點barrier都發出後，任務就開始處理之前緩衝的資料。在處理並發出所有緩衝資料之後，任務就可以繼續正常處理輸入流了。最終，檢查點分界線會到達輸出（sink）任務。當sink任務接收到barrier時，它也會先執行「分界線對齊」，然後將自己的狀態儲存到檢查點，並向jobmanager確認已接收到barrier。一旦從應用程式的所有任務收到乙個檢查點的確認資訊，jobmanager就會將這個檢查點記錄為已完成。。這樣，當發生故障時，我們就可以用已完成的檢查點恢復應用程式了。
這種檢查點演算法可以在不停止整個應用程式的情況下，生成一致的分布式檢查點。但是，它可能會增加應用程式的處理延遲。flink對此有一些調整措施，可以在某些場景下顯得對效能的影響沒那麼大。
當任務將其狀態儲存到檢查點時，它其實處於乙個阻塞狀態，而此時新的輸入會被快取起來。由於狀態可能變得非常大，而且檢查點需要通過網路將資料寫入遠端儲存系統，檢查點的寫入很容易就會花費幾秒到幾分鐘的時間——這對於要求低延遲的應用程式而言，顯然是不可接受的。在flink的設計中，真正負責執行檢查點寫入的，其實是狀態後端。具體怎樣複製任務的狀態，取決於狀態後端的實現方式。例如，檔案系統（filesystem）狀態後端和rocksdb狀態後端都支援了非同步（asynchronous）檢查點。觸發檢查點操作時，狀態後端會先建立狀態的本地副本。本地拷貝完成後，任務就將繼續常規的資料處理，這往往並不會花費太多時間。乙個後台執行緒會將本地快照非同步複製到遠端儲存，並在完成檢查點後再回來通知任務。非同步檢查點的機制，顯著減少了任務繼續處理資料之前的等待時間。此外，rocksdb狀態後端還實現了增量的檢查點，這樣可以大大減少要傳輸的資料量。
方法三：基於方法二對精確一次要求不嚴格的低延時演算法
為了減少檢查點演算法對處理延遲的影響，另一種技術是調整分界線對齊的步驟。對於需要非常低的延遲、並且可以容忍「至少一次」（at-least-once）狀態保證的應用程式，flink可以將檢查點演算法配置為，在等待barrier對齊期間處理所有到達的資料，而不是把barrier已經到達的那些分割槽的資料快取起來。當檢查點的所有barrier到達，運算元任務就會將狀態寫入檢查點——當然，現在的狀態中，就可能包括了一些「提前」的更改，這些更改由本該屬於下乙個檢查點的資料到來時觸發。如果發生故障，從檢查點恢復時，就將再次處理這些資料：這意味著檢查點現在提供的是「至少一次」（at-least-once）而不是「精確一次」（exactly-once）的一致性保證。
flink 保證一致性的 barrier對 齊
barrier對 齊 1.什麼是barrier對 齊？旦operator從輸 入流接收到checkpoint barrier n，它就不能處理 來 該流的任何資料記錄，直到它從其他所有輸入接收到barrier n為止。否則，它會混合屬於快照n的記錄和屬於快照n 1的記錄接收到barrier n的流暫...
Flink基礎 一致性的3個級別
1 at most once 這其實是沒有正確性保障的委婉說法，故障發生後，計數可能丟失。2 at least once 這表示計數結果可能大於正確值，但是絕不會小於正確值，即計數程式發生故障後可能多算，但是絕不會少計算。3 exactly once 這是指系統保證在故障發生後得到的計數結果與正確值...
MySQL資料一致性檢查的幾個工具
1 mysql checksum命令 在執行checksum命令時，表會被加乙個讀鎖 read lock checksum table的原理是對錶中的資料進行一行一行的較驗和計算，因些對於大表，這是乙個很耗時的過程。如果對於myisam表，建表時加上checksum 1選項，那麼在對這樣的表進行ch...