設計 Kafka 主題 - 許多主題與一個大主題

Question

考慮到一系列不同的事件，推薦的方法是

• 一個包含所有事件的大主題
• 不同類型事件的多個主題

哪個選項會更好？

我知道消息不在主題的同一分區中，這意味着沒有順序保證，但在做出此決定時是否還有其他因素需要考慮？

Answer 1

主題是邏輯抽象，應包含相同類型的消息。 假設您監控網站並捕獲點擊流事件，另一方面，您有一個數據庫將其更改填充到更改日志主題中。 您應該有兩個不同的主題，因為點擊流事件與您的數據庫更改日志無關。

這有多個優點：

• 您的數據將具有不同的格式，並且您將需要不同的（反）序列化程序來寫入讀取數據（使用單個主題您將需要一個混合序列化程序，並且在讀取數據時您將無法獲得類型安全）
• 您將有不同的消費者應用程序，一個應用程序可能只對點擊流事件感興趣，而第二個應用程序只對數據庫更改日志感興趣，而第三個應用程序對兩者都感興趣。 如果您有多個主題，應用程序一和應用程序二只訂閱他們感興趣的主題——如果您只有一個主題，應用程序一和應用程序二需要閱讀所有內容並過濾他們不感興趣的內容，增加經紀人，網絡，客戶端可以加載嗎

Answer 2

正如@Matthias J. Sax 之前所說，這里沒有金子彈。 但我們必須考慮不同的主題。

空調：訂購交貨

如果您的應用程序需要保證訂單交付，您只需要處理一個主題，以及需要保證它的那些消息的相同密鑰。

如果訂購不是強制性的，游戲開始......

所有消息的模式是否相同？

消費者是否會對相同類型的不同事件感興趣？

消費者方面會發生什么？，我們是在減少還是增加在實現、可維護性、錯誤處理方面的復雜性……？

水平可擴展性對我們重要嗎？ 更多的主題通常意味着更多的可用分區，這意味着更多的水平擴展能力。 它還允許在代理端進行更准確的可擴展性配置，因為我們可以選擇每種事件類型增加的分區數量。 或者在消費者方面，每個事件類型有多少消費者站起來。

對每種消息類型並行消費有意義嗎？ ...

從技術上講，如果我們允許消費者微調要消費的那些類型的事件，我們就有可能減少從代理向消費者發送不需要的消息所需的網絡帶寬，以及所有這些事件的反序列​​化數量（使用的 CPU，隨着時間的推移，更多的免費資源，能源成本降低......）。

同樣值得記住的是，在不同的主題中拆分不同類型的消息並不意味着必須使用不同的 Kafka 消費者來消費它們，因為它們允許同時從不同的主題消費。

好吧，這個問題沒有明確的答案，但我有一種感覺，對於 Kafka，因為具有多種功能，如果不需要有序交付，我們應該將每種類型的消息拆分為不同的主題。