Apache Pulsar分散式事務機制

banq發表於2022-03-09
Apache分散式

Pulsar 事務 (txn) 使事件流應用程式能夠在一個原子操作中消費、處理和生成訊息。開發此功能的原因可以總結如下。

隨著流處理的興起，對具有更強處理保障的流處理應用的需求也隨之增長。
例如，在金融行業，金融機構使用流處理引擎為使用者處理借記和貸記。這種型別的用例要求每條訊息都只處理一次，無一例外。
換句話說，如果流處理應用程式消費訊息 A 並將結果生成為訊息 B (B = f(A))，那麼恰好一次處理保證意味著只有當且僅當 B 是時，A 才能被標記為已消費成功生產，反之亦然。
Pulsar事務API加強了流處理的訊息交付語義和處理保證。
它使流處理應用程式能夠在一個原子操作中消費、處理和生產訊息。
這意味著，一個事務中的一批訊息可以從許多主題分割槽接收、產生並被確認。
一個事務中涉及的所有操作的成功或失敗都是一個單一的原子單元。
 
Pulsar生產者的侷限性
透過使用Pulsar的idempotent冪等生產者可以避免資料丟失或重複，但是它並不能為跨多個分割槽的寫入提供保證。

在Pulsar中，最高階別的訊息傳遞保證是在一個單一分割槽使用具有精確一次語義的idempotent生產者，也就是說，每個訊息被精確地持久化一次，沒有資料損失和重複。然而，這個解決方案也有一些侷限性。
  • 由於序列ID單調遞增，該方案僅適用於單個分割槽和單個生產者會話內（即生產一條訊息），因此在向一個或多個分割槽生產多條訊息時沒有原子性。
    在這種情況下，如果在生產和接收訊息的過程中出現一些故障（例如，client/broker/bookie 崩潰、網路故障等），訊息會被重新處理和重新傳遞，這可能會導致資料丟失或資料重複：
    • 對於生產者：如果生產者重試傳送訊息，一些訊息會被持久化多次；如果生產者不重試傳送訊息，一些訊息會被持久化一次，而另一些訊息會丟失。
    • 對於消費者：由於消費者不知道broker是否收到訊息，消費者可能不會重試傳送ack，導致收到重複訊息。
  • 類似地，對於 Pulsar Function，它只保證單個事件上的冪等函式的語義只有一次，而不是處理多個事件或產生多個可能發生的結果。
    例如，如果一個函式接受多個事件併產生一個結果（例如，視窗函式），則該函式可能會在產生結果和確認傳入訊息之間失敗，甚至在確認單個事件之間失敗，這會導致所有（或部分）傳入訊息被重新傳遞和重新處理，並生成新的結果。
    但是，許多場景需要跨多個分割槽和會話的原子保證。
  • 消費者需要依賴更多的機制來一次確認（ack）訊息。
    例如，消費者需要儲存 MessgeID 及其確認狀態。主題解除安裝後，訂閱可以在再次載入主題時恢復記憶體中這個MessgeID的acked狀態。

相關文章