比較Apache Pulsar 和Apache Kafka：統一排隊和流式傳輸 - splunk

banq發表於2022-01-18
ApacheKafka

訊息傳遞模型是使用者在選擇流式訊息傳遞系統時應該考慮的第一件事。訊息傳遞模型應涵蓋以下 3 個方面：
  • 訊息消費 - 訊息是如何傳送和消費的？
  • 訊息確認 - 如何確認訊息？
  • 郵件保留 - 郵件保留多長時間、觸發刪除的原因以及如何刪除？

  

訊息消費
在現代實時流式架構中，訊息傳遞用例可以分為兩類：排隊和流式傳輸。
排隊

排隊 是無序或 共享的 訊息傳遞。使用佇列訊息傳遞，建立多個消費者以從單個點對點訊息傳遞通道接收訊息。當通道傳遞訊息時，任何消費者都可能收到它。訊息系統的實現決定了哪個消費者實際接收到訊息。
排隊用例通常與無狀態應用程式結合使用。無狀態應用程式不關心排序，但它們 確實 需要能夠確認或刪除單個訊息以及儘可能擴充套件消費並行性的能力。典型的基於佇列的訊息系統包括 RabbitMQ 和 RocketMQ。
流媒體
相比之下， 流媒體 是嚴格有序或 排他的 訊息傳遞。使用流式訊息傳遞，始終只有一個消費者在使用訊息傳遞通道。消費者按照寫入的確切順序接收從通道傳送的訊息。
流用例通常與有狀態的應用程式相關聯。有狀態的應用程式關心排序及其狀態。訊息的順序決定了有狀態應用程式的狀態。當發生亂序消費時，排序將影響應用程式需要應用的任何處理邏輯的正確性。
 在面向微服務或事件驅動的架構中，流式傳輸 和排隊都是必需的。
 

Apache Pulsar模型
Apache Pulsar 將排隊和流式統一到一個統一的訊息模型中：  producer-topic-subscription-consumer。主題（分割槽）是用於傳送訊息的命名通道。每個主題分割槽都由儲存在 Apache BookKeeper中的分散式日誌支援。釋出者釋出的每條訊息僅在主題分割槽上儲存一次，然後複製以儲存在多個 bookie（BookKeeper 伺服器）上，並且消費者可以根據需要多次使用。
話題Topic是消費的真相源泉。儘管訊息在主題分割槽上只儲存一次，但可以有不同的方式來使用這些訊息。消費者被組合在一起以消費訊息。每組消費者都是一個主題的訂閱。每個消費者組都可以有自己的訊息消費方式——獨佔、共享或故障轉移——這在不同的消費者組之間可能不同。這將佇列和流式處理結合在一個模型和 API 中，其設計和實現的目標是不影響效能和引入成本開銷，同時還為使用者提供了很大的靈活性，以最適合用例的方式消費訊息在眼前。

  • 獨家訂閱（流媒體）

顧名思義，訂閱（消費者組）中只能有一個消費者在任何給定時間使用主題分割槽。
  • 故障轉移訂閱（流）

使用故障轉移訂閱，多個消費者可以附加到同一個訂閱。然而，對於給定的主題分割槽，一個消費者將被選為該主題分割槽的主消費者。其他消費者將被指定為故障轉移消費者。當主消費者斷開連線時，分割槽將被重新分配給故障轉移消費者之一進行消費，而新分配的消費者將成為新的主消費者。
  • 共享訂閱（排隊）

使用共享訂閱，您可以將任意數量的消費者附加到同一個訂閱。訊息在多個消費者之間以迴圈分發的方式傳遞，任何給定的訊息都只傳遞給一個消費者。當消費者斷​​開連線時，所有傳遞給它但未確認的訊息將被重新安排傳送給在該訂閱上存活的剩餘消費者。
 
獨佔訂閱和故障轉移訂閱僅允許每個訂閱的每個主題分割槽有一個使用者。他們按分割槽順序消費訊息。它們最適用於需要嚴格排序的流用例。另一方面，共享訂閱允許每個主題分割槽有多個消費者。同一訂閱中的每個消費者只接收發布到主題分割槽的部分訊息。共享訂閱最適合不需要排序的排隊用例，並且可以將消費者數量擴充套件到分割槽數量之外。
Pulsar 中的訂閱實際上與 Apache Kafka 中的消費者組相同。建立訂閱具有高度可擴充套件性且非常便宜。您可以根據需要建立任意數量的訂閱。同一主題的不同訂閱不必屬於相同的訂閱型別。這意味著您可以在同一主題上擁有一個包含 10 個使用者的故障轉移訂閱和一個包含 20 個使用者的共享訂閱。如果共享訂閱處理事件很慢，可以在不改變分割槽數量的情況下，向共享訂閱新增更多消費者。
除了統一訊息 API 之外，由於 Pulsar 主題分割槽實際上是儲存在 Apache BookKeeper 中的分散式日誌，因此它還提供了一個閱讀器 API（類似於消費者 API，但沒有遊標管理）供使用者完全控制如何自己消費訊息。
 

訊息確認
使用跨機器分佈的訊息傳遞系統時，可能會發生故障。在消費者從訊息系統中的主題消費訊息的情況下，消費訊息的消費者和為主題分割槽提供服務的訊息代理都可能失敗。當發生此類故障時，一旦一切恢復，能夠從消費者停止的地方恢復消費是很有用的，這樣您就不會錯過訊息，也因此您不必處理已經確認的訊息. 恢復點在 Apache Kafka 中通常稱為偏移量，更新恢復點的過程稱為訊息確認，或提交偏移量。
在 Apache Pulsar 中，遊標用於跟蹤每個訂閱的訊息確認。每當消費者在主題分割槽上確認訊息時，都會更新遊標。更新遊標確保消費者不會再次收到訊息。然而，遊標並不是 Apache Kafka 中的簡單偏移量。游標更多。
Apache Pulsar 有兩種方式來確認訊息，單獨確認或累積確認。透過累積確認，消費者只需要確認它收到的最後一條訊息。主題分割槽中直到（包括）提供訊息 id 的所有訊息都將被標記為已確認，並且不會再次重新傳遞給消費者。累積確認實際上與 Apache Kafka 中的偏移量更新相同。
Apache Pulsar 的不同之處在於能夠單獨確認，也就是選擇性確認。消費者能夠單獨確認訊息。確認的訊息將不會被重新傳遞。圖 5 說明了 ack 個人和 ack 累積之間的區別（灰色框中的訊息被確認並且不會被重新傳遞）。在圖的頂部，它顯示了 ack 累積的示例，M12 之前（和包括）的訊息被標記為 acked。在圖的底部，它顯示了單獨響應的示例。只有訊息 M7 和 M12 被確認 - 在消費者失敗的情況下，所有訊息都將被重新傳遞，除了 M7 和 M12。
獨佔或故障轉移訂閱中的消費者能夠單獨或累積地確認訊息；而共享訂閱中的消費者只允許單獨確認訊息。單獨確認訊息的能力為處理消費者故障提供了更好的體驗。對於某些應用程式來說，防止重新傳遞已經確認的訊息非常重要，因為對於那些應用程式來說，處理訊息可能需要很長時間或者非常昂貴。
選擇訂閱型別和確認方法的靈活性允許 Pulsar 在一個簡單的統一 API 中支援各種訊息傳遞和流式處理用例。
 

訊息保留
與傳統的訊息傳遞系統相比，訊息在被確認後不會立即被刪除。Pulsar brokers 僅在收到訊息確認時更新游標。只有在所有訂閱都已經使用它之後才能刪除訊息（訊息在其遊標中標記為已確認）。但是，Pulsar 還允許您將訊息保留更長時間，即使在所有訂閱都已經使用它們之後。這是透過配置訊息保留期來完成的。
 
下表列出了 Apache Pulsar 和 Apache Kafka 的異同：

  • Kafka

更專注於流式傳輸，分割槽上的獨家訊息傳遞。沒有共享消費。
簡單的偏移管理
  1. 在 Kafka 0.8 之前，偏移量儲存在 ZooKeeper 中
  2. 在 Kafka 0.8 之後，偏移量儲存在偏移量主題上

根據保留刪除訊息。如果消費者在保留期之前沒有閱讀訊息，它將丟失資料。
不支援 TTL。
  • Pulsar

統一的訊息傳遞模型和 API。
  1. 透過獨佔的故障轉移訂閱流式傳輸
  2. 透過共享訂閱排隊

訊息僅在所有訂閱都使用它們後才會被刪除。即使訂閱的消費者長時間停機，也不會丟失資料。即使在所有訂閱都使用它們之後，也允許訊息保留配置的保留期。
支援訊息TTL。

Apache Pulsar 將高效能流（Apache Kafka 追求）和靈活的傳統佇列（RabbitMQ 追求）結合到一個統一的訊息傳遞模型和 API 中。Pulsar 使用統一的 API 為您提供了 一個 用於流式處理和排隊的系統，具有相同的高效能。

相關文章