1. Flink 的容錯機制（checkpoint）
Checkpoint機制是Flink可靠性的基石，可以保證Flink叢集在某個運算元因為某些原因(如 異常退出)出現故障時，能夠將整個應用流圖的狀態恢復到故障之前的某一狀態，保證應用流圖狀態的一致性。Flink的Checkpoint機制原理來自“Chandy-Lamport algorithm”演算法。
每個需要Checkpoint的應用在啟動時，Flink的JobManager為其建立一個 CheckpointCoordinator(檢查點協調器)，CheckpointCoordinator全權負責本應用的快照製作。
CheckpointCoordinator(檢查點協調器)，CheckpointCoordinator全權負責本應用的快照製作。 
-
CheckpointCoordinator(檢查點協調器) 週期性的向該流應用的所有source運算元傳送 barrier(屏障)。
-
當某個source運算元收到一個barrier時，便暫停資料處理過程，然後將自己的當前狀態製作成快照，並儲存到指定的持久化儲存中，最後向CheckpointCoordinator報告自己快照製作情況，同時向自身所有下游運算元廣播該barrier，恢復資料處理
-
下游運算元收到barrier之後，會暫停自己的資料處理過程，然後將自身的相關狀態製作成快照，並儲存到指定的持久化儲存中，最後向CheckpointCoordinator報告自身快照情況，同時向自身所有下游運算元廣播該barrier，恢復資料處理。
-
每個運算元按照步驟3不斷製作快照並向下遊廣播，直到最後barrier傳遞到sink運算元，快照製作完成。
-
當CheckpointCoordinator收到所有運算元的報告之後，認為該週期的快照製作成功; 否則，如果在規定的時間內沒有收到所有運算元的報告，則認為本週期快照製作失敗。
文章推薦：
2. Flink Checkpoint與 Spark 的相比，Flink 有什麼區別或優勢嗎
Spark Streaming 的 Checkpoint 僅僅是針對 Driver 的故障恢復做了資料和後設資料的 Checkpoint。而 Flink 的 Checkpoint 機制要複雜了很多，它採用的是輕量級的分散式快照，實現了每個運算元的快照，及流動中的資料的快照。
3. Flink 中的 Time 有哪幾種
Flink中的時間有三種型別，如下圖所示：
-
Event Time：是事件建立的時間。它通常由事件中的時間戳描述，例如採集的日誌資料中，每一條日誌都會記錄自己的生成時間，Flink通過時間戳分配器訪問事件時間戳。
-
Ingestion Time：是資料進入Flink的時間。
-
Processing Time：是每一個執行基於時間操作的運算元的本地系統時間，與機器相關，預設的時間屬性就是Processing Time。
例如，一條日誌進入Flink的時間為2021-01-22 10:00:00.123，到達Window的系統時間為2021-01-22 10:00:01.234，日誌的內容如下：
2021-01-06 18:37:15.624 INFO Fail over to rm2
對於業務來說，要統計1min內的故障日誌個數，哪個時間是最有意義的？—— eventTime，因為我們要根據日誌的生成時間進行統計。
4. 對於遲到資料是怎麼處理的
Flink中 WaterMark 和 Window 機制解決了流式資料的亂序問題，對於因為延遲而順序有誤的資料，可以根據eventTime進行業務處理，對於延遲的資料Flink也有自己的解決辦法，主要的辦法是給定一個允許延遲的時間，在該時間範圍內仍可以接受處理延遲資料：
-
設定允許延遲的時間是通過allowedLateness(lateness: Time)設定
-
儲存延遲資料則是通過sideOutputLateData(outputTag: OutputTag[T])儲存
-
獲取延遲資料是通過DataStream.getSideOutput(tag: OutputTag[X])獲取
文章推薦：
Flink 中極其重要的 Time 與 Window 詳細解析
5. Flink 的執行必須依賴 Hadoop 元件嗎
Flink可以完全獨立於Hadoop，在不依賴Hadoop元件下執行。但是做為大資料的基礎設施，Hadoop體系是任何大資料框架都繞不過去的。Flink可以整合眾多Hadooop 元件，例如Yarn、Hbase、HDFS等等。例如，Flink可以和Yarn整合做資源排程，也可以讀寫HDFS，或者利用HDFS做檢查點。
6. Flink叢集有哪些角色？各自有什麼作用
有以下三個角色：
JobManager處理器：
也稱之為Master，用於協調分散式執行，它們用來排程task，協調檢查點，協調失敗時恢復等。Flink執行時至少存在一個master處理器，如果配置高可用模式則會存在多個master處理器，它們其中有一個是leader，而其他的都是standby。
TaskManager處理器：
也稱之為Worker，用於執行一個dataflow的task(或者特殊的subtask)、資料緩衝和data stream的交換，Flink執行時至少會存在一個worker處理器。
Clint客戶端：
Client是Flink程式提交的客戶端，當使用者提交一個Flink程式時，會首先建立一個Client，該Client首先會對使用者提交的Flink程式進行預處理，並提交到Flink叢集中處理，所以Client需要從使用者提交的Flink程式配置中獲取JobManager的地址，並建立到JobManager的連線，將Flink Job提交給JobManager
7. Flink 資源管理中 Task Slot 的概念
在Flink中每個TaskManager是一個JVM的程式, 可以在不同的執行緒中執行一個或多個子任務。 為了控制一個worker能接收多少個task。worker通過task slot（任務槽）來進行控制（一個worker至少有一個task slot）。
8. Flink的重啟策略瞭解嗎
Flink支援不同的重啟策略，這些重啟策略控制著job失敗後如何重啟：
- 固定延遲重啟策略
固定延遲重啟策略會嘗試一個給定的次數來重啟Job，如果超過了最大的重啟次數，Job最終將失敗。在連續的兩次重啟嘗試之間，重啟策略會等待一個固定的時間。
- 失敗率重啟策略
失敗率重啟策略在Job失敗後會重啟，但是超過失敗率後，Job會最終被認定失敗。在兩個連續的重啟嘗試之間，重啟策略會等待一個固定的時間。
- 無重啟策略
Job直接失敗，不會嘗試進行重啟。
9. Flink 是如何保證 Exactly-once 語義的
Flink通過實現兩階段提交和狀態儲存來實現端到端的一致性語義。分為以下幾個步驟：
開始事務（beginTransaction）建立一個臨時資料夾，來寫把資料寫入到這個資料夾裡面
預提交（preCommit）將記憶體中快取的資料寫入檔案並關閉
正式提交（commit）將之前寫完的臨時檔案放入目標目錄下。這代表著最終的資料會有一些延遲
丟棄（abort）丟棄臨時檔案
若失敗發生在預提交成功後，正式提交前。可以根據狀態來提交預提交的資料，也可刪除預提交的資料。
文章推薦：
八張圖搞懂 Flink 端到端精準一次處理語義 Exactly-once
10. 如果下級儲存不支援事務，Flink 怎麼保證 exactly-once
端到端的 exactly-once 對 sink 要求比較高，具體實現主要有冪等寫入和事務性寫入兩種方式。
冪等寫入的場景依賴於業務邏輯，更常見的是用事務性寫入。而事務性寫入又有預寫日誌（WAL）和兩階段提交（2PC）兩種方式。
如果外部系統不支援事務，那麼可以用預寫日誌的方式，把結果資料先當成狀態儲存，然後在收到 checkpoint 完成的通知時，一次性寫入 sink 系統。
11. Flink是如何處理反壓的
Flink 內部是基於 producer-consumer 模型來進行訊息傳遞的，Flink的反壓設計也是基於這個模型。Flink 使用了高效有界的分散式阻塞佇列，就像 Java 通用的阻塞佇列（BlockingQueue）一樣。下游消費者消費變慢，上游就會受到阻塞。
12. Flink中的狀態儲存
Flink在做計算的過程中經常需要儲存中間狀態，來避免資料丟失和狀態恢復。選擇的狀態儲存策略不同，會影響狀態持久化如何和 checkpoint 互動。Flink提供了三種狀態儲存方式：MemoryStateBackend、FsStateBackend、RocksDBStateBackend。
13. Flink是如何支援流批一體的
這道題問的比較開闊，如果知道Flink底層原理，可以詳細說說，如果不是很瞭解，就直接簡單一句話：Flink的開發者認為批處理是流處理的一種特殊情況。批處理是有限的流處理。Flink 使用一個引擎支援了 DataSet API 和 DataStream API。
14. Flink的記憶體管理是如何做的
Flink 並不是將大量物件存在堆上，而是將物件都序列化到一個預分配的記憶體塊上。此外，Flink大量的使用了堆外記憶體。如果需要處理的資料超出了記憶體限制，則會將部分資料儲存到硬碟上。Flink 為了直接操作二進位制資料實現了自己的序列化框架。
15. Flink CEP 程式設計中當狀態沒有到達的時候會將資料儲存在哪裡
在流式處理中，CEP 當然是要支援 EventTime 的，那麼相對應的也要支援資料的遲到現象，也就是watermark的處理邏輯。CEP對未匹配成功的事件序列的處理，和遲到資料是類似的。在 Flink CEP的處理邏輯中，狀態沒有滿足的和遲到的資料，都會儲存在一個Map資料結構中，也就是說，如果我們限定判斷事件序列的時長為5分鐘，那麼記憶體中就會儲存5分鐘的資料，這在我看來，也是對記憶體的極大損傷之一。
文章推薦：