實時數據的處理一致性如何保證？

摘要：在當今快速發展的數字化世界中，實時數據處理變得至關重要。無論是金融服務、在線零售、社交媒體還是物聯網 (IoT)，實時數據流爲企業提供了即時的洞察和決策支持。然而，隨着數據量的激增和處理速度的加快，保證數據的一致性成爲了一個巨大挑戰。

• 實時數據一致性的定義以及面臨的挑戰

• 實時數據處理系統如何保障一致性

01 實時數據一致性的定義以及面臨的挑戰

數據一致性通常指的是數據在整個系統或多個系統中保持準確、可靠和同步的狀態。在實時數據處理中，一致性包括但不限於數據的準確性、完整性、時效性和順序性。

下圖是典型的實時 / 流式數據處理的流程：

1、流式數據以各種方式推送到 kafka 中

2、flink 流式數據處理引擎將數據處理

3、處理完成的數據寫入到 Mpp 數據庫

由於整個數據鏈條是動態變化，因此，實時數據的一致性面臨一些挑戰。

高併發處理： 實時系統需要處理大量併發數據流，增加了一致性維護的難度。主要是在分佈式數據庫端，如何處理高併發的寫入？

網絡延遲和故障： 網絡問題可能導致數據傳輸中斷或延遲，影響數據同步。主要是在數據處理過程中如何保障數據處理的一致性？

02 實時數據處理系統如何保障一致性

數據源和數據處理之間採用消息隊列

緩衝機制： 使用消息隊列作爲緩衝，平衡數據生產者和消費者之間的速度差異。

順序保證： 確保消息按照發送順序被處理。

Flink 引擎在故障下保持數據一致性策略

數據重放（Data Replay）

1. 概念： 數據重放是指在發生故障後，系統能夠重新處理之前已經處理過的數據，以確保數據的完整性和一致性。

2. 實現： Flink 通過保存輸入數據流的快照（snapshots），在發生故障時，可以從快照中恢復數據，並重新處理從故障點之後的數據。

狀態恢復（State Recovery）

1. 概念： Flink 作業由多個操作符組成，每個操作符可能有自己的狀態（例如，計數器、聚合結果等）。狀態恢復是指在故障發生後，能夠恢復這些狀態到故障前的狀態。

2. 實現： Flink 定期對操作符的狀態進行快照（checkpointing），並將快照存儲在持久化存儲中。如果作業失敗，Flink 可以從最近的快照中恢復狀態，並從故障點繼續處理。

通過狀態恢復和數據重放，Flink 確保即使在發生故障的情況下，也能保持數據處理的端到端一致性。並且 Flink 提供了端到端的精確一次（exactly-once）處理語義，確保每條數據在系統中只被處理一次，即使在故障發生時也是如此。

故障處理流程

1. 故障檢測： Flink 監控作業的運行狀態，一旦檢測到節點故障，立即啓動故障恢復流程。

2. 狀態恢復： Flink 從最近的快照中恢復作業的狀態，包括每個操作符的內部狀態。

3. 數據重放： Flink 重新處理從故障點之後的數據，確保所有數據都被正確處理。

4. 作業重啓： 在狀態和數據恢復之後，Flink 重啓作業，從故障點繼續執行。

Flink 引擎在網絡延遲下保持數據一致性策略

Flink 引擎解決數據延遲到達的現象主要通過以下幾種策略：

1. 時間語義： Flink 支持不同的時間語義（事件時間、處理時間和攝取時間），允許開發者根據業務需求處理數據的時效性問題。

2. 水印機制（Watermarks）： Flink 使用水印來處理事件時間的數據流。水印是一種用於表示時間進度的機制，可以告訴 Flink 在特定時間之前的所有事件都已到達，可以進行處理。這允許系統處理亂序事件或延遲到達的數據。

3. 窗口技術： Flink 提供了多種窗口操作，如滾動窗口（tumbling windows）、滑動窗口（sliding windows）和會話窗口（session windows），這些窗口可以對數據進行分組並在指定的時間範圍內聚合，從而處理數據到達的延遲。

4. 狀態管理： Flink 允許操作符維護狀態，即使數據延遲到達，也可以在狀態中保留必要的信息，直到數據真正到達時再進行處理。

5. 允許亂序和延遲的 API： Flink 提供了 allowedLateness 參數，允許在窗口操作中指定一定的延遲容忍度，窗口會爲延遲數據保留狀態，直到延遲數據到達後進行處理。

MPP 數據庫在高併發情況下保持數據一致性策略

分佈式數據庫在設計的時候會考慮高併發情況下保持數據一致性的策略，主要有使用事務管理，數據分區分片，數據版本控制，以及採用最終一致性原理。

1、使用事務管理： MPP 數據庫一般會提供 ACID 事務屬性，確保事務具有原子性，一致性、隔離性和持久性，另外在分佈式系統中支持分佈式事務，使用兩階段提交等協議來維護事務一致性。

2、數據分區分片： 將數據分佈到不同的分區或分片上，減少單個節點的負載，提高併發處理能力。數據分區分片時採用一致性哈希算法來分配數據到不同的節點，即使在節點增減的情況下也能保持數據分佈的一致性。

3、 數據版本控制： 當多個事務或操作可能同時對同一數據進行修改時，數據版本控制可以確保數據庫的一致性和完整性。另外，數據版本控制可以實現多版本併發控制（MVCC），允許在不鎖定資源的情況下執行讀取和寫入操作，從而提高系統的併發性能。在分佈式系統中，不同節點可能會對同一數據產生衝突的更新，版本控制機制可以幫助識別和解決這些衝突。

4、採用最終一致性模型： 大部分分佈式數據庫採用 CAP 定理，接受短暫的數據不一致，最終一致性。

在實時數據處理流程中，從技術架構的設計到數據處理引擎的實現，再到分佈式數據庫在面對高併發、系統故障和網絡異常等挑戰時確保數據一致性的機制，都需要開發人員在開發和部署階段進行精心的規劃和應用。通過合理利用這些功能，可以有效地維護數據的完整性和一致性。

注：分佈式數據庫的設計和操作深受 CAP 定理的影響，該定理指出在分佈式系統中，以下三個特性不可能同時得到完全滿足：

1. 一致性（Consistency）：在分佈式系統中的所有數據副本上，對於任何更新操作，都能保證所有節點在同一時間看到最新的數據。

2. 可用性（Availability）：每個請求接收到一個響應，無論是成功還是失敗的響應。

3. 分區容錯性（Partition Tolerance）：在網絡分區（即系統的一部分被網絡故障隔離）發生的情況下，系統仍然能夠繼續運行。

在 CAP 定理的框架下，分佈式數據庫需要在這三個特性之間做出權衡：

• 強一致性與可用性的權衡：如果一個分佈式數據庫優先考慮一致性，那麼在更新數據時可能需要鎖定相關的數據副本，直到所有副本都更新完畢。這可能會降低系統的可用性，因爲在更新過程中，其他操作可能需要等待。

• 最終一致性：在這種模型下，分佈式數據庫接受在數據更新後的短時間內數據可能不一致，但保證系統最終會達到一個數據一致的狀態。這種模型通常通過版本控制、數據版本控制、衝突解決策略等技術實現，允許系統在更新過程中繼續處理請求，但返回的數據可能是舊版本。

• 分區容錯性：對於分佈式數據庫來說，網絡分區是一種常見情況，因此數據庫需要設計爲即使在分區發生時也能繼續提供服務。這通常意味着犧牲一定程度的一致性或可用性，例如，通過使用最終一致性模型來保證系統的持續運行。

在實際應用中，分佈式數據庫可能採用以下策略來實現 CAP 定理中的權衡：

• 數據副本和同步策略：選擇合適的數據副本數量和同步方式，以平衡一致性和可用性。

• 讀寫分離：通過分離讀操作和寫操作，可以在保持高可用性的同時，通過異步複製機制逐步達到數據一致性。

• 衝突解決機制：在檢測到數據衝突時，使用預定義的策略來解決衝突，如 “最後寫入勝出” 或基於特定業務邏輯的自定義策略。

• 智能路由和負載均衡：在網絡分區發生時，智能地路由請求到可用的節點，並在後臺同步數據，以保持系統的可用性和一致性。

• 使用不同的一致性模型：根據業務需求，選擇強一致性、最終一致性或其他一致性模型，以適應不同的應用場景。

最終，分佈式數據庫的設計者和運維人員需要根據具體的業務需求、系統特點和預期的工作負載來決定如何在 CAP 定理的三個特性之間做出最佳權衡。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/yvkJRWV48KnSWOcby9Otvw