<譯>流計算容錯

這篇文檔描述了Flink的流式計算的容錯機制

• Introduction
• Checkpointing
  • Barriers
  • State
  • Exactly Once vs. At Least Once
• Recovery

簡介

Flink提供容錯機制來對應用數據流提供持續的恢復。這個機制保證了即便在出現錯誤的狀況下，記錄也只會被處理一次。注意，這裏有一個開關來降級擔保至少處理一次（接下來會詳細介紹）。

容錯機制會持續不斷地對分佈式數據流畫快照。對於一些小狀態的流式應用來講，這些快照是很輕量級的，不會非性能形成太大影響。這些流式應用的狀態都被保存在一個可配置的地方（如master node或HDFS）

一旦程序出錯（多是機器故障，網絡故障，或者一些軟件缺陷），Flink會中止這些分佈式的數據流。系統會重啓它們並重置到最近的一次正常的檢查點。輸入流會重置到快照點。任何重啓後數據流的已經被處理的記錄會被確保不會回到以前的檢查點狀態，也就是說不會再從新去走一遍已經走過的路。

注意：爲充分發揮這個機制的保障，數據源（如消息隊列或broker）須要支持可以將數據流倒回到一個已定義最近的點，Apache Kafka支持這樣，Flink和Kafka鏈接會充分發揮其能力。

注意：由於Flink的檢查點是經過分佈式快照來實現的，咱們使用字符快照和可交換的檢查點

檢查點

Flink容錯機制最核心的部分就是對分佈式流和operater的狀態持續不斷地畫快照。這些快照做爲持續不斷的檢查點來保證一旦程序出現問題後能夠回滾。畫快照的機制在「Lightweight Asynchronous Snapshots for Distributed Dataflows」裏有介紹。它的靈感來自於分佈式快照的Chandy-Lamport 算法，而且是轉爲Flink設計的執行模型

Barriers

Flink分佈式快照裏的核心元素是brarriers。這些brarris被注入到數據流中成爲數據流的一部分。brarris不會超越前面的數據，它們嚴格線性流動。brarrier 將一個數據流中的記錄分離到即將進入目前的一個快照、下一個快照裏面去的集合。也就是說brarrier將數據流劃分爲多個段，每一段去不一樣的快照。每個brarrier都帶有一個它前面數據即將去的那個快照的ID。Barriers不會中斷數據流而且都是很是的輕量級。屬於多個快照的多個barriers可以在同一時刻子啊同一個留裏面出現，這意味着多個快照可能同步發生。

barriers在數據源端被注入到並行的數據流中。快照n（記爲Sn）對應的barriers被注入的位置與該快照所覆蓋的數據區域有關。好比說，在Kafka中，這個位置就是在分區中的最後一條數據的偏移。Sn這個位置會傳遞給檢查點的coordinator（Flink job 管理器）。

接下來barriers會繼續往下流。當一箇中間位置的operator從它全部的輸入流中接收到快照n的barrier，它會將這個barrier發送到它輸出的全部流裏面。當一個sink operator（也就是DAG的終點）從它的全部輸入流中接收到barrier n，它會將快照n上報到coordinator。當全部的sink 組件都對快照n進行確認以後，就能夠被認爲處理完畢了。

當快照n被處理完畢的時候，能夠肯定的是快照n以前的記錄都已經被處理完畢了。由於這些記錄（以及它們後面的記錄）都已經流經了整個拓撲。

有多個輸入流的operater須要根據快照將各個流對齊。如下是對上圖的解釋：

• 一旦operator從任何一個流裏面接收到快照n的barrier，在所有接收其它流中快照n的barrier以前，此operator就再也不接收這條流裏面的任何記錄。然而，這些已經接收的記錄可能將快照n的記錄和快照n+1的記錄混雜了（由於來的時候的數據不能保證按序到達）。
• Streams that report barrier n被暫時擱置。從這些流裏面接收到的數據暫時不回被處理，而是先存放到緩衝區。
• 一旦從最後一條輸流裏面接收到barrier n，opertor發出全部正在等待發出的記錄，而後發出快照n的barrier.
• 從這之後，恢復從流裏面讀取記錄，在從流裏面讀取數據以前，得先讀完緩衝區裏面的記錄。

State

operators可能包含各類形式的State，這些state一樣也會成爲快照的一部分。operator的state來自如下幾種形式：

• 用戶自定義state：這是直接由transformation方法（就像 map()或者filter()）來建立和修改的一種state。自定義的state能夠是一個簡單變量，也能夠是與function關聯的key/value狀態（詳情參考State in Streaming Applications）
• 系統state:這種狀態是用在部分在operator計算緩衝區裏面的緩衝數據。一個典型的例子就是窗口緩衝，在這種狀態中，系統會不斷給窗口收集（或聚合）記錄，直到這個窗口被處理成功後發送。.

operators會在收到全部輸入流的barrier後及時地對他們的狀態進行快照，而後再將barriers發送到輸入流。在這個時刻，barriers以前的記錄對state的更新都已經被記錄，在barriers以後的記錄會對state形成的更新都不會被應用。由於一個快照的狀態多是比較大的，它被存儲在一個可配置的後端state裏。默認狀況下，這部分使用的是jobManager的內存，可是在重要的設置步驟中，應該配置一個值得信賴的存儲系統（好比HDFS）。state被存儲以後，operator會對快照進行確認，將快照的barrier發送到輸出流，而後繼續處理。

剛生成的快照如今包含：

• 對每個數據流，在該數據流中該快照的起始位置
• 對每個opertor，有一個指向做爲該快照一部分的state的指針

一次處理語義和至少一次性語義

數據流對齊的步驟可能會對程序增長延時。一般狀況下，由於這個致使的延時控制在幾毫秒以內，可是在某些存在不正常數據的狀況下咱們發現延時增長明顯。對於應用程序來講一般但願對全部記錄保持保持低延遲（幾毫秒），Flink有一個開關來跳過流對齊的步驟，檢查點的快照機制依然會保持運行。在收到全部流的barrier後對檢查點進行快照。

在對齊步驟跳事後，operator保持對各輸入流的處理，即使是在只有某些流的barrier到達，依然對這些流繼續處理，不擱置（之前會擱置直到全部流對快照 n 的barrier都到達這個operator）。在一次恢復以後，這些記錄可能會重複出現，由於它們都被包含在快照n裏面，會在快照n以後重現

注意：對齊步驟只應該在須要jion操做以及多個發出流（在流被從新分區或shuffle以後）的狀況下才須要啓用。由於那些只有一些簡單並行流操做（如 map(),flatMap(),filter(),...）的流事實上就已經提供了至少處理一次語義。

恢復

恢復機制是很簡單直接的：在一次錯誤發生的時候，Flink選取最近的一次成功的檢查點 k。而後系統重如今這個快照中的整個分佈式流，並提供每一個operator在此快照中的檢查點 k 時的狀態。數據源被設置爲從Sk位置開始讀取。好比在Kafka中，意思就是被告知從偏移爲Sk的地方開始消費。

若是快照被不正確地記錄，operator會從最近一次正確的快照開始，將接下來的快照增量更新到此state