本文為您介紹檢查點和快照逾時的診斷方法和調優策略。
運行原理
Flink的狀態管理核心機制依賴於Chandy-Lamport演算法，以確保資料的一致性和可靠性。在此架構下，檢查點和快照的執行過程可以概括為兩個主要階段：
同步階段：此階段的關鍵在於Barrier的對齊和同步資源的維護。Barrier作為一種特殊的資料記錄，在運算元之間傳遞時，其對齊的時間與資料記錄的延遲成正相關關係。
非同步階段：在此階段運算元會將本地狀態資料上傳至遠端持久化儲存系統，上傳時間的長短與狀態資料的大小成正比。
當Flink作業面臨反壓問題時，同步階段的執行可能會變得緩慢，從而導致檢查點和快照逾時。因此，在遇到檢查點和快照逾時問題，並且監測到作業存在反壓時，應首先參考SQL作業大狀態導致反壓的調優原理與方法和DataStream作業大狀態導致反壓的調優原理與方法優先解決反壓問題，以提高作業的整體效率和穩定性。
問題診斷方法
在反壓問題解決後，如果檢查點與快照仍出現逾時現象，則首先應分析同步階段的對齊時間是否過長，隨後考慮是否由龐大的狀態資料引起。
Checkpoint UI
在頁面作業日誌頁簽下的中，觀察不同層級（作業、運算元、單並發）的Checkpoint指標，分析檢查點和快照逾時原因。
您可以著重觀察逾時的Checkpoint的異常運算元或進行中的Checkpoint的運算元，定位思路如下：
其Sync Duration和Alignment Duration是否較長：如是，則可基本判定其瓶頸在同步階段上，需要優先解決同步階段問題。
其Async Duration是否較長，以及其Checkpointed Data Size是否較大：如是，則可基本判定其瓶頸在非同步階段狀態上傳上。
Checkpoint指標
在頁面監控警示頁簽查看lastCheckpointDuration和lastCheckpointSize指標，來粗粒度分析歷史Checkpoint的耗時和大小。
調優策略
在進行效能調優之前，首先要確保運行時效能達到預期。如果當前效能水平不足，應優先根據運行時效能最佳化指南進行調整。在滿足基本效能要求後，為了進一步提高檢查點和快照的效率，可以考慮以下策略。
策略 | 策略說明 | 使用情境 | 配置方法 | 注意事項 |
使用Unaligned Checkpoint和Buffer Debloating | 可以有效解決因等待資料對齊而導致的逾時問題，適用於各種規模的作業。 | 檢查點或快照同步逾時 | 運行參數中配置，詳情請參見Unaligned checkpoints和Buffer debloating使用方式。 | 請參見Limitations。 |
增加運行時的並發資源 | 通過增加並發資源，可以減少單個並發任務的狀態量，從而加速非同步快照的處理流程。 | 檢查點或快照非同步逾時 | 在資源配置或細粒度資源配置中增加並發，詳情請參見配置作業資源。 | 無。 |
使用原生快照 | 相比標準快照，原生快照產生速度更快，儲存佔用更小。 | 快照非同步逾時 | 對運行中的作業，建立原生格式的作業快照，詳情請參見手動建立作業快照。 | 原生快照無法保證跨大版本相容。 |
相關文檔
大狀態作業導致的問題和大狀態作業診斷調優整體思路詳情，請參見大狀態作業調優實踐指南。
Flink SQL由最佳化器根據配置項以及SQL語句來推導產生狀態運算元，想要高效處理有狀態的大規模資料和效能調優，需要對SQL狀態運算元產生機制、管理原則、診斷方法和調優方法有一定瞭解，詳情請參見SQL作業大狀態導致反壓的調優原理與方法。
Flink Datastream API在狀態管理方面提供了靈活的介面，您可以採取相關措施來確保狀態大小可控，避免狀態的無限制增長，詳情請參見DataStream作業大狀態導致反壓的調優原理與方法。
從檢查點或快照中恢複作業會需要從遠程儲存中下載狀態檔案並重建狀態引擎，容易成為恢複過程中的效率瓶頸，可能會造成作業的長時間停滯。恢複過程的瓶頸問題的診斷方法和調優策略詳情，請參見作業啟動和擴縮容速度最佳化。