Kafka 消費者離開消費者組

Question

我是卡夫卡的新手。 我遇到了以下場景，我有入站和出站 Kafka 隊列。 應用程序從入站隊列中讀取消息，對其進行處理（調用 10 個下游服務），成功后，將消息放入出站隊列，然后將消息提交到入站隊列。

1. 快樂的情況，當所有下游依賴項都正常工作時，沒問題。
2. 糟糕的情況，當我們的硬依賴項（我的意思是沒有我的服務的硬依賴項無法繼續）失敗了 x 小時，我們會重試，在結果准備好后，我們將其放入出站隊列，然后將其提交到入站隊列，由於消息輪詢時間之間有很長的等待時間，我們在提交入站隊列時遇到了以下問題，

WARN [kafka-coordinator-heartbeat-thread]  [Consumer clientId=604dd51a-9b36-4490-aa80-51125bafb465, groupId=abc] This member will leave the group because consumer poll timeout has expired. This means the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms, which typically implies that the poll loop is spending too much time processing messages. You can address this either by increasing max.poll.interval.ms or by reducing the maximum size of batches returned in poll() with max.poll.records. 

INFO [kafka-coordinator-heartbeat-thread] - [Consumer clientId=604dd51a-9b36-4490-aa80-51125bafb465, groupId=abc] Member 604dd51a-9b36-4490-aa80-51125bafb465-e0 sending LeaveGroup request to coordinator zk2-abc.com:9092 (id: 214748 rack: null)

我面臨兩個問題，

1. 重復數據處理，因為消息被發送到出站隊列，然后我試圖提交到入站隊列。
2. 當我的消費者忙於處理消息時，在某個階段它從消費者列表中取出，消費者在嘗試提交數據時意識到這一點。

我理解建議的解決方案是設置“max.poll.interval.ms”，只要它處理消息所需的時間，但我知道事情好的時候的處理時間，但不確定我的硬依賴何時失敗，因為我必須這樣做等待依賴服務響應（重試）。 我可以設置為最大可用時間，但不確定這是否是好的方法以及在 kafka 級別的含義是什么。

我試過的，

1. 使用 kafka 消費者的暫停、輪詢和恢復方法來確保我的消費者還活着
2. 使用 max.poll.interval.ms 的最大可用時間，不用擔心處理時間。

我想了解我必須處理上述問題的可能解決方案以及每個問題的優缺點。

Answer 1

您可以專門為消息處理創建另一個線程，因此消費者線程在調用poll()時永遠不會延遲。

您可以創建一個處理線程pool （足夠大，在嘗試分配新消息時不會減慢使用者線程的速度），或者將背壓保存在內部結構中，例如ConcurrentHashMap或某種同步的Deque/Queue尺寸。 您的“處理器”線程將完成繁重的工作，因此消費者能夠及時調用poll 。

希望它有幫助，寫生銹！

這取自 Kafka Consumer 文檔：

我們有意避免實現特定的線程模型進行處理。 這為實現記錄的多線程處理留下了幾個選項。

1. 每個線程一個消費者

一個簡單的選擇是為每個線程提供自己的使用者實例。 以下是這種方法的優缺點： PRO：最容易實現 PRO：它通常是最快的，因為不需要線程間協調 PRO：它使基於每個分區的順序處理非常易於實現（每個線程僅按接收消息的順序處理消息）。 CON：更多的消費者意味着更多的 TCP 連接到集群（每個線程一個）。 一般來說，Kafka 非常有效地處理連接，所以這通常是一個很小的成本。 缺點：多個消費者意味着更多的請求被發送到服務器，數據的批處理略少，這可能會導致 I/O 吞吐量下降。 CON：所有進程的總線程數將受到分區總數的限制。

2. 解耦消費和處理

另一種選擇是擁有一個或多個消費者線程來完成所有數據消費，並將 ConsumerRecords 實例移交給由實際處理記錄處理的處理器線程池消耗的阻塞隊列。 此選項同樣有利有弊： PRO：此選項允許獨立擴展消費者和處理器的數量。 這使得可以有一個單一的消費者來提供許多處理器線程，從而避免對分區的任何限制。 CON：保證處理器之間的順序需要特別小心，因為線程將獨立執行，由於線程執行時間的運氣，較早的數據塊實際上可能在較晚的數據塊之后被處理。 對於沒有訂購要求的加工，這不是問題。 缺點：手動提交位置變得更加困難，因為它需要所有線程協調以確保該分區的處理完成。 這種方法有許多可能的變化。 例如，每個處理器線程可以有自己的隊列，消費者線程可以使用 TopicPartition 散列到這些隊列中，以確保按順序使用並簡化提交。