關聯Kafka和動態主題

Question

我正在使用Kafka構建一個相關系統。 假設有一個服務A執行數據處理，並且有數千個客戶端B向其提交作業。 B是短命的，它們出現在網絡上，將數據推送到A然后發生兩件重要的事情：

1. B將立即從A獲得狀態;
2. B然后將完全退出，保持在線以接收有關狀態的進一步更新，或者偶爾會重新開啟以檢查狀態。

（這與網格計算或mpi沒有什么不同）。

這兩點都應該使用眾所周知的correlationId概念來實現： B擁有一個唯一的id（在我的情況下是UUID），它在頭文件中發送給A ，而頭文件又用它作為Reply-To主題發送狀態更新至。 這意味着它必須動態創建主題，它們無法預先確定。

我打開了auto.create.topics.enable ，它確實動態地創建了主題，但是現有的消費者並不知道它們並且需要重新啟動[以獲取主題元數據，我想，如果我理解文檔正確的話]。 我還檢查了消費者的metadata.max.age.ms設置，但它似乎沒有幫助，即使我將它設置為一個非常低的值。

據我所知，這還沒有答案，即： kafka過濾/動態主題創建 ， kafka消費者動態檢測添加的主題 ， Kafka制作人可以創建主題和分區嗎？ 或回答不滿意。

由於有數百個A和數千個B ，我不可能使用共享主題或類似的東西，以免我的網絡過載。 我可以使用Kafka的AdminTools或其他任何東西預先創建主題，但我發現它有些愚蠢（盡管我看到人們使用它與Zookeeper和Kafka基礎設施本身交談的現實例子）。

所以問題是，是否有一種方法可以動態創建Kafka主題，使消費者和生產者能夠在不重新啟動的情況下了解它？ 並且，在最壞的情況下，AdminTools真的會幫助它，我必須在哪一方使用它 - A或B ？

Kafka 0.11, Java 8

更新使用AdminClient創建主題無論出於何種原因都沒有幫助，當我嘗試訂閱時，消費者仍然會拋出LEADER_NOT_AVAILABLE 。

Answer 1

建議不要創建無限數量的主題。 我建議您重新設計拓撲/系統。

我曾想過自己制作動態主題但后來才意識到，最終zookeeper會因為過時的主題而耗盡內存（想象一年后可以創建多少個主題）。 如果您確保在創建的主題上有一些上限，這可能會有效。 整體來說是行政頭痛。

如果您使用Kafka查詢請求響應，您會發現其他人也說這樣做很尷尬（ Kafka是否支持請求響應消息 ）。

Answer 2

好的，所以我會回答我自己的問題。

1. 使用AdminClient創建主題僅在創建相應的使用者之前執行。
2. 改變了我的拓撲結構，考慮到1）並在消息頭中引入了相關id的交換（與JMS中相同）。 我還必須實現某些拓撲管理方法，將B分組到容器中。

應該注意的是，正如許多人所說的，這僅在B s處於單一消費者群體並且使用1個分區監聽主題時才有效。

為了了解我正在進行的工作，你可能會看看我一直致力於https://github.com/ikonkere/magic的中間件框架。