KMQ：基於Apache Kafka的可靠性訊息佇列

banq發表於2021-06-14
MQApacheKafka佇列

當從Apache Kafka接收訊息時，只能確認所有訊息的處理達到給定的偏移量。由於這種機制，如果出現任何問題並且我們的處理元件出現故障，重新啟動後它將從最後提交的偏移量開始處理。
但是，在某些情況下，您真正​​需要的是選擇性訊息確認，正如“傳統”訊息佇列RabbitMQ或ActiveMQ一樣：也就是說，我們要一個一個地確認訊息的處理。例如，當與外部系統整合時，這可能很有用，其中每條訊息對應於一個外部呼叫並且可能會失敗。
如果訊息在配置的時間段內未得到確認，則會重新傳送並重試處理。這正是Amazon SQS 的工作方式。
這種行為也可以在 Kafka 之上實現，這就是kmq所做的。它使用一個額外的markers主題，需要跟蹤處理已經開始和結束的訊息。
 

KMQ
使用kmq您可以確認 Kafka 中單個訊息的處理，並在超時後重新傳送未確認的訊息。這與通常的 Kafka 偏移提交機制形成對比，使用該機制您可以僅確認給定偏移量以內的所有訊息。
確認機制使用一個marker主題，該主題應該具有與“主”資料主題（稱為queue主題）相同數量的分割槽。標記主題用於透過為每條訊息編寫開始/結束標記來跟蹤已處理的訊息。

KMQ：基於Apache Kafka的可靠性訊息佇列


處理訊息的流程如下：

  1. 從queue主題中批次讀取訊息
  2. 為每條訊息向markers主題寫一個start標記，訊息會等待等到這個標記被寫入
  3. 向queue主題提交最大的訊息偏移量
  4. 處理訊息
  5. 對於每條訊息，寫一個end標記。無需等到標記寫入。

這確保至少處理每條訊息一次。請注意，可以從不同的執行緒、伺服器或應用程式對每條訊息分別、亂序地確認每條訊息（寫入 end標記）。
 
使用的應用程式kmq應包含以下元件：
  • 一些RedeliveryTrackers。該元件使用marker主題並在適當時重新傳遞訊息。應在群集中啟動多個副本以進行故障轉移。使用自動分割槽分配。
  • 將資料傳送queue到要處理的主題的元件
  • 佇列客戶端，自定義或使用 KmqClient

 
依賴：

<dependency>
    <groupId>com.softwaremill.kmq</groupId>
    <artifactId>core_2.12</artifactId>
    <version>0.2</version>
</dependency>

相關文章