文章目錄

• 狀態一致性
• • 什么是狀態一致性
  • 狀態一致性種類
  • 端到端（end-to-end）狀態一致性
  • Sink端到端狀態一致性的保證
  • Flink+Kafka端到端狀態一致性的保證

---

狀態一致性

什么是狀態一致性

• 有狀態的流處理，內部每個算子任務都可以有自己的狀態。

• 對于流處理器內部（沒有接入sink）來說，所謂的狀態一致性，其實就是我們所說的計算結果要保證準確，一條數據不應該丟失，也不應該重復計算。

• 在遇到故障時可以恢復狀態，恢復以后的重新計算，結果應該也是完全正常的。

  
  

狀態一致性種類

• 最多一次（At-Most-Once）

  • 任務發生故障時最簡單的措施就是既不恢復丟失的狀態，也不重放丟失的事件，所以至多一次是最簡單的一種情況。

  • 它保證了每個事件至多被處理一次。

• 至少一次（At-Least-Once）

  • 對于大多數現實應用而言，用戶的期望是不丟事件，這類保障被稱為至少一次。
  • 它意味著所有事件最終都會處理，雖然有些可能會處理多次。

• 精確一次（Exactly-Once）

  • 精確一次是最嚴格，最難實現的一類保障。
  • 它不但能夠保證事件沒有丟失，而且每個事件對于內部狀態的更新都只有一次。
  • Flink利用Checkpoints機制來保證精確一次語義。

端到端（end-to-end）狀態一致性

端到端的保障指的是在整個數據處理管道上結果都是正確的。在每個組件都提供自身的保障情況下，整個處理管道上端到端的保障會受制于保障最弱的那個組件。

那么端到端的精確一次在各部分又是如何實現的呢？

• 內部：Checkpoints機制，在發生故障的時候能夠恢復各個環節的數據。
• Source：可設置數據讀取的偏移量，當發生故障的時候重置偏移量到故障之前的位置。
• Sink：從故障恢復時，數據不會重復寫入外部系統。

其中前兩種在上文已經介紹過了，下面就介紹一下Sink如何提供端到端的精確一次性保障。

Sink端到端狀態一致性的保證

應用若是想提供端到端的精確一次性保障，就需要一些特殊的Sink連接器，根據情況不同，這些連接器可以使用兩種技術來實現精確一次保障：

• 冪等性寫（idempotent write）

  • 冪等操作的含義就是可以多次執行，但是只會引起一次改變。
  • 例如我們將相同的鍵值對插入一個哈希結構中就是一個冪等操作， 因為由于該鍵值對已存在后，無論插入多少次都不會改變結果。
  • 由于可以在不改變結果的前提下多次執行，因此冪等性寫操作在一定程度上減輕Flink檢查點機制所帶來的重復結果的影響

• 事務性寫（transactional write）

  • 事務性寫其實就是原子性寫，即只有在上次成功的檢查點之前計算的結果才會被寫入外部Sink系統。
  • 事務性寫雖然不會像冪等性寫那樣出現重放過程中的不一致現象，但是會增加一定延遲，因為結果只有在檢查點完成后才對外可見。
  • 實現思想：構建的事務對應著Checkpoints，待Checkpoints真正完成的時候，才把所有對應的結果寫入Sink系統中。
  • 實現方式：
    • 預寫日志（Write Ahead Log，WAL）
    • 兩階段提交（Two Phase Commit，2PC）

  
  

預寫日志

• 把結果數據先當成狀態保存，然后在收到Checkpoints完成的通知時，一次性寫入Sink系統。
• 簡單易于實現，由于數據提前在狀態后端做了緩存，所以無論什么Sink系統都能用這種方式一批搞定。
• 但同時它也存在問題，寫入數據時出現故障則會導致一部分數據成功一部分失敗。
• DataStream API提供了一個模板類GenericWriteAheadSink，來實現這種事務性Sink。

兩階段提交

• 對于每個Checkpoints，Sink任務會啟動一個事務，并將接下來所有接收的數據添加到事務里。
• 然后將這些數據寫入外部 Sink，但不提交它們，這時只是“預提交”。
• 當它收到Checkpoints完成的通知時，它才正式提交事務，實現結果的真正寫入。
• 這種方式真正實現了精確一次，它需要一個提供事務支持的外部Sink系統，Flink提供了TwoPhaseCommitSinkFunction接口。
• 對外部Sink系統的要求
  • 外部Sink系統必須提供事務支持，或者Sink任務必須能夠模擬外部系統上的事務。
  • 在Checkpoints的隔離期間里，必須能夠開啟一個事務并接受數據寫入。
  • 在收到Checkpoints完成的通知之前，事務必須是“等待提交”的狀態。在故障恢復的情況下，這可能需要一些時間。如果這個時候 Sink系統關閉事務（例如超時了），那么未提交的數據就會丟失。
  • Sink任務必須能夠在進程失敗后恢復事務。
  • 提交事務必須是冪等操作。

不同Source和Sink的一致性保證

Flink+Kafka端到端狀態一致性的保證

• 內部：利用Checkpoints機制把狀態保存，當發生故障的時候可以恢復狀態，從而保證內部的狀態一致性。

• source 端：Kafka Consumer作為Source，可以將偏移量保存下來，當發生故障時可以從發生故障前的偏移量重新消費數據，從而保證一致性。

• sink端：Kafka Producer作為Sink，采用兩階段提交Sink，需要實現一個TwoPhaseCOmmitSinkFunction。

總結

以上是生活随笔為你收集整理的Flink 状态一致性：端到端状态一致性的保证的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。