1.3.5　Flink故障恢復

在Flink作業的執行過程中，除正常執行的流程外，還有可能由于環境等原因導致各種類型的錯誤。整體來講，錯誤可分為兩大類：Task執行出現錯誤或Flink集群的Master出現錯誤。由于錯誤不可避免，為了提高可用性，Flink需要提供自動錯誤恢復機制進行重試。

對于第一類Task執行錯誤，Flink提供了多種不同的錯誤恢復策略。

（1）第一種錯誤恢復策略是restart-all，即直接重啟所有的Task。對于Flink的流任務，由于Flink提供了checkpoint機制，因此當任務重啟后可以直接從上次的checkpoint開始繼續執行，因此這種方式更適合于流作業。

（2）第二種錯誤恢復策略是restart-individual，它只適用于Task之間沒有數據傳輸的情況。在這種情況下，可以直接重啟出錯的Task。

由于Flink的批作業沒有checkpoint機制，因此對于需要數據傳輸的作業，直接重啟所有的Task會導致作業從頭計算，從而導致一定的性能問題。為了增強對批作業的處理，Flink在1.9版本中引入了一種新的基于分區的錯誤恢復策略。

在一個Flink的批作業中，Task之間存在兩種數據傳輸方式，一種是管道（pipeline）類型的方式，這種方式上下游Task之間直接通過網絡傳輸數據，因此需要上下游同時運行；另外一種是blocking類型的方式，這種方式下，上游的Task會首先將數據進行緩存，因此上下游的Task可以單獨執行。基于這兩種類型的傳輸，Flink將ExecutionGraph中使用管道方式傳輸數據的Task的子圖叫作分區（region），從而將整個ExecutionGraph劃分為多個子圖。分區內的Task必須同時重啟，而不同分區的Task由于在分區邊界存在blocking的邊，因此，可以單獨重啟下游分區中的Task。

基于這一思路，如果某個分區中的某個Task執行出現錯誤，可以分兩種情況進行考慮。

（1）如果是由于Task本身的問題發生錯誤，則可以只重啟該Task所屬的分區中的所有Task，這些Task重啟之后，可以直接拉取上游分區緩存的輸出結果繼續進行計算，這個過程如圖1-19所示。

（2）另一方面，如果錯誤是由于讀取上游結果出現問題，如網絡連接中斷、緩存上游輸出數據的TaskManager異常退出等，則還需要重啟上游分區來重新產生相應的數據。在這種情況下，如果上游分區輸出的數據分發方式不是確定性的（如keyBy、broadcast是確定性的分發方式，而rebalance、random則不是，因為每次執行會產生不同的分發結果），為了保證結果的正確性，還需要同時重啟上游分區所有的下游分區，這個過程如圖1-20所示。

另一類異常是Flink集群的Master進程發生異常。目前Flink支持啟動多個Master作為備份，這些Master可以通過ZooKeeper進行選主Master，從而保證某一時刻只有一個Master在運行。當前活躍的Master發生異常時，某個備份的Master可以接管協調的工作。為了保證Master可以準確維護作業的狀態，Flink目前采用了一種最簡單的實現方式，即直接重啟整個作業。實際上，由于作業本身可能仍在正常運行，因此這種方式存在一定的改進空間。