作为@matthias j。萨克斯说过这里没有金弹。但我们必须考虑不同的主题。
护发素：定货
如果您的应用程序需要保证订单交付，那么您只需要使用一个主题，以及那些需要保证交付的消息的相同键。
如果命令不是强制性的，游戏就开始了。。。
所有消息的架构是否相同？
消费者会对相同类型的不同活动感兴趣吗？
消费者方面会发生什么？我们是在减少还是在增加实现、可维护性、错误处理等方面的复杂性。。。？
横向可伸缩性对我们来说重要吗？更多的主题通常意味着更多的可用分区，这意味着更多的水平可伸缩性容量。它还允许在代理端进行更精确的可伸缩性配置，因为我们可以选择每个事件类型增加多少分区。或者在消费者方面，每个事件类型有多少消费者站出来。
将每个消息类型的消耗并行化有意义吗。。。
从技术上讲，如果我们允许使用者对要使用的事件类型进行微调，那么我们就有可能减少从代理向使用者发送不需要的消息所需的网络带宽，加上所有这些消息的反序列化次数（使用的cpu，这使得随着时间的推移，更多的可用资源、能源成本降低……）。
同样值得记住的是，在不同的主题中拆分不同类型的消息并不意味着必须与不同的kafka消费者一起使用它们，因为它们允许同时使用不同主题的消息。
好吧，这个问题没有一个明确的答案，但我有一种感觉，Kafka，因为多个功能，如果订购交付是不需要的，我们应该把我们的信息在不同的主题每种类型的分裂。

主题是逻辑抽象，应该包含相同类型的消息。比方说，您监视一个网站并捕获点击流事件，另一方面，您有一个数据库将其更改填充到changelog主题中。您应该有两个不同的主题，因为click stream事件与数据库changelog无关。
这有多重优势：
您的数据将具有不同的格式，并且您将需要不同的（反）序列化程序来写入和读取数据（使用单个主题，您将需要一个混合序列化程序，并且在读取数据时将无法获得类型安全性）
您将有不同的使用者应用程序，其中一个应用程序可能只对click stream事件感兴趣，而第二个应用程序只对数据库changelog感兴趣，第三个应用程序对这两者都感兴趣。如果你有多个主题，应用程序1和2只订阅他们感兴趣的主题——如果你只有一个主题，应用程序1和2需要阅读所有内容，过滤他们不感兴趣的内容，增加代理、网络、客户端的负载