apache-kafka - apache-kafka 拥有 1 亿个主题

Question

我正在尝试用 apache-kafka 替换 rabbit mq，在规划时，我遇到了几个概念规划问题。

首先，我们将 rabbit mq 用于每个用户队列策略，这意味着每个用户使用一个队列。这符合我们的需要，因为每个用户都代表要与该特定用户完成的一些工作，并且如果该用户导致问题，则队列将永远不会与其他用户发生问题，因为队列是分开的(问题意味着队列中的消息将被分派(dispatch)发给使用 http 请求的用户。如果用户拒绝接收消息(服务器可能宕机？)，它将返回重试队列，这将不会导致消息丢失(除非队列宕机))

现在 kafka 具有容错性和故障安全性，因为它写入磁盘。
这正是我试图在我们的结构中实现 kafka 的原因。

但我的计划有问题。

首先，我正在考虑为每个用户创建尽可能多的主题，这意味着每个用户都会拥有每个主题(这会导致什么问题？我的最大估计是我将拥有大约 1~500 万个主题)

其次，如果我决定基于用户id的随机哈希的操作和分区来选择主题，如果一个用户当前没有消费消息的问题，分区中的所有用户都必须等待吗？构建这种情况的最佳方法是什么？

总而言之，1~5百万用户。我们不希望一个用户阻止大量其他正在处理的用户。每个用户都有主题将解决这个问题，如果有这么大的数量进入，zookeeper 似乎可能会出现问题(这是真的吗？)

什么是结构化的最佳解决方案？考虑可扩展性？

Answer 1

First, I was thinking to create as many topic as per user meaning each user would have each topic (What problem will this cause? My max estimate is that I will have around 1~5 million topics)

我建议不要这样建模。

谷歌一下“kafka topic limits”，你会发现这个主题的相关注意事项。我想你会发现你不想制作数百万个主题。

Second, If I decide to go for topics based on operation and partition by random hash of users id

是的，为这些消息设置一个主题，然后根据相关字段路由这些消息，例如 user_id或 conversation_id .该字段可以作为消息中的字段出现并用作 ProducerRecord key用于确定该消息的目的地是主题中的哪个分区。我不会将操作包含在主题名称中，而是包含在消息本身中。

if there was a problem with one user not consuming message currently, will the all user in the partition have to wait ? What would be the best way to structure this situation?

这取决于用户如何使用消息。您可以设置一个超时，然后将消息路由到某个“失败”主题。或者以 UDP 样式向用户发送消息，无需确认。有很多方法可以对此进行建模，并且在不知道您的消费者如何将消息转发给您的客户的情况下提供建议是很困难的。

此外，如果您使用的是 Kafka Streams，请记下 StreamPartitioner 界面。该界面出现在 KStream和 KTable将消息具体化到主题的方法，并且在您有客户端空闲在特定 TCP 连接上的聊天应用程序中可能很有用。