设计卡夫卡话题 - 多个主题与一个大话题

Question

考虑到不同事件的流，建议的方式是

• 包含所有事件的一个重要主题
• 针对不同类型的活动的多个主题

哪个选项更好？

我了解消息不在主题的同一分区中，这意味着没有订单保证，但在制作此消息时是否有任何其他因素需要考虑决定？

Answer 1

主题是逻辑抽象，应包含相同类型的消息。让我们说，您监控一个网站并捕获点击流事件，另一方面，您有一个数据库，可以将其更改为更改日志主题。您应该有两个不同的主题，因为单击流事件与您的数据库更改日志无关。

这有很多好处：

• 您的数据将具有不同的格式，您需要使用不同的（de）序列化程序来读取数据（使用单个主题，您需要使用混合序列化程序，并且在读取数据时不会获得类型安全性）
• 您将拥有不同的消费者应用程序，一个应用程序可能只对点击流事件感兴趣，而第二个应用程序仅对数据库更改日志感兴趣，第三个应用程序对两者都感兴趣。如果您有多个主题，应用程序一和二只订阅他们感兴趣的主题 - 如果您有一个主题，应用程序一两个需要阅读所有内容并过滤他们对增加代理，网络不感兴趣的内容，可以加载客户端

Answer 2

就像@Matthias J. Sax所说的那样，这里没有金弹。但是我们必须考虑不同的主题。

护发素：订购的货物

如果您的应用程序需要保证订单交付，则只需处理一个主题，并为需要保证的消息加上相同的键。

如果不是必须订购，则游戏开始...

所有消息的架构都一样吗？

消费者会对相同类型的不同事件感兴趣吗？

消费者端会发生什么？我们是否正在降低或增加实施，可维护性，错误处理方面的复杂性？？

水平可伸缩性对我们重要吗？更多主题通常意味着更多的可用分区，这意味着更大的水平可伸缩性容量。此外，由于我们可以选择每种事件类型要增加的分区数量，因此它可以在代理端进行更准确的可伸缩性配置。或在消费者方面，每种事件类型代表多少消费者。

将每种消息类型的消耗并行化是否有意义？ ...

从技术上讲，如果我们允许消费者微调要使用的事件类型，则可能会减少从代理向消费者发送不希望的消息所需的网络带宽，以及所有这些事件的反序列​​化数量（cpu ，随着时间的推移，这将释放更多的自由资源，降低能源成本...。

还值得记住的是，将不同类型的消息拆分为不同的主题并不意味着必须与不同的Kafka使用者一起使用它们，因为它们允许同时从不同的主题进行使用。

好吧，这个问题没有一个明确的答案，但是我有Kafka的感觉，因为有多种功能，如果不需要有序交付，我们应该在不同主题中按类型划分消息。