我试图用apache-kafka代替Rabbit mq，并且在规划时遇到了一些概念性规划问题。
首先，我们对每个用户队列策略使用Rabbit mq，这意味着每个用户使用一个队列。这符合我们的需要，因为每个用户代表要与该特定用户一起完成的某项工作，并且如果该用户引起问题，则该队列将永远不会与其他用户有问题，因为队列是分开的（问题的含义是将调度队列中的消息使用http请求发送给用户。如果用户拒绝接收消息（服务器可能关闭了？），它将返回重试队列，这不会导致消息丢失（除非队列关闭）
现在，由于卡夫卡已写入磁盘，因此它具有容错能力和故障安全性。这正是我尝试在我们的结构中实施kafka的原因。
但是我的计划有问题。
首先，我正在考虑为每个用户创建尽可能多的主题，这意味着每个用户将拥有每个主题（这将导致什么问题？我的最大估计是我将拥有大约1到500万个主题）
其次，如果我决定通过基于用户ID的随机散列的操作和分区来寻找主题，如果当前有一个用户不使用消息的问题，分区中的所有用户都必须等待吗？解决这种情况的最佳方法是什么？
因此，结论是1〜500万用户。我们不想让一个用户阻止大量正在处理的其他用户。每个用户都有一个主题可以解决此问题，如果这么多的用户进入，zookeeper似乎可能有问题（这是真的吗？）
什么是结构化的最佳解决方案？考虑可扩展性？