回覆列表
-
1 # 你看我獨角獸嗎
-
2 # 宋先生oovv
你指的是分割槽發生變化嗎。分割槽發生變化，比如你增加分割槽，是不會去rebalance的。也沒有必要。新增分割槽 只會均勻落的個個分割槽。如果你生產者 指定寫個個分割槽的策略的話，自己就能控制，沒影響
-
3 # 給自己的福音
topic變化是指刪除了麼，我覺得你想說的是patitions或者replica變化以後的重新分配。假如consume不變，並且都是由伺服器指定分割槽，對於produce還是對key取模去不同partition。不過重新分配的話，consume可能也要重新快取partition吧。我是新手哈哈
是這樣的，在Kafka中，每個主題都分為一組分割槽。生產者將訊息寫到分割槽的尾部，而消費者則按照自己的步調閱讀它們。Kafka透過在消費者組之間分配分割槽來擴充套件主題的使用，消費者組是一組共享公共組識別符號的消費者。下圖描述了具有三個分割槽的單個主題和具有兩個成員的使用者組。
對於每個消費者組，選擇一個經紀人作為小組協調員。小組協調員負責，管理消費者群體狀態。在以下情況下將分割槽分配給使用者：
產生了一個新的消費者。一個老消費者倒下了。主題元資料發生變化。將分割槽重新分配給使用者的過程稱為使用者組重新平衡，當組首次連線到代理時：
消費者根據配置auto.offset.reset從每個分割槽的最早或最新偏移量開始讀取。然後按順序讀取每個分割槽中的訊息。使用者提交其已成功處理的訊息的偏移量。在下圖中，使用者的位置在偏移量6上，並且其最後提交的偏移量在偏移量1上。
重新平衡使用者組後，會將新的使用者分配到一個分割槽。
它從最後提交的偏移量開始讀取。如果舊使用者處理了一些訊息但在提交已處理訊息的偏移量之前崩潰了，它將重新處理一些訊息。瞭解Kafka如何利用該poll方法來協調和重新平衡消費群體，這是一些自動提交使用者程式碼示例：
如果使用者在提交抵消成功處理的訊息之前崩潰，則該分割槽的新使用者將重複處理已處理的未提交訊息。頻繁提交可減輕重新平衡/崩潰後重復項的數量。在上面的示例程式碼中，Kafka使用者庫基於配置的auto.commit.interval.ms值自動提交，減小該值會增加提交頻率。
某些應用程式可能選擇手動提交以更好地管理訊息使用，因此讓我們討論一下手動提交的不同策略。對於手動提交，我們需要將auto.commit.enable設定為false，並在事件迴圈中適當地使用KafkaConsumer.commitSync。