问题描述
我正在尝试构建类似 Ably 的 PaaS，在其中为用户提供易于使用的发布/订阅系统。问题是我打算使用 Kafka，但我不知道它是否适合于此。每个用户可以在 PaaS 中拥有任意数量的应用程序，每个应用程序都会收到不同的消息，我认为 PaaS 中的每个应用程序都会在 Kafka 中有一个主题，但如果我得到，应用程序的数量可以增长到数百万甚至数十亿很多用户和 Kafka 不适合这么多主题。
我应该为此使用 Kafka 还是研究其他东西？也许还有其他一些我不知道的应用程序之间的消息分离方式。我不能将所有内容都放在一个主题中，因为那样我会在节点上收到数万亿条不必要的消息。
解决方法
对于您的 kafka 问题部分：
2021 年 3 月更新： 使用 Kafka 的新 KRaft 模式（“Kafka Raft 元数据模式”的缩写；在 Kafka v2.8 的早期访问中），它从 Kafka 的架构中完全删除了 ZooKeeper，一个 Kafka集群可以处理数百万个主题/分区。有关详细信息，请参阅 https://www.confluent.io/blog/kafka-without-zookeeper-a-sneak-peek/。
由于上述功能尚不推荐用于生产使用的架构当前限制是由 zookeeper 支持的 kafka 集群中的数千个主题/分区
如果您想为其他应用程序和客户提供一些服务，最好提供不同的主题，以便您可以利用身份验证和授权机制来避免用户访问其他用户的数据。
,免责声明：我能干地工作并领导我们围绕 Kafka 的一些工作
首先，Ably 不是用 Kafka 构建的，Kafka 非常unsuited to the task of a service like Ably，就像 Ably 没有做 Kafka 所做的一样。 Kafka 是一个非常强大的工具，拥有丰富的生态系统，但弹性可扩展性并不重要。扩展主题/分区是一个缓慢的过程，将节点添加到正在运行的活动集群不是您可以“做”的事情。但是，work great together
有更适合这种情况的流媒体解决方案，如 Apache Pulsar 或 Redis (PubSub/Streams)，但它再次回到权衡。 Pulsar 更适合推送订阅，具有功能并且可以做更多事情。 Redis 集群可以弹性快速地扩展。权衡是 Pulsar 的运行、管理和扩展非常复杂，而 Redis 默认是短暂的。还有其他解决方案，如 NATS
Ably 中有很多技术可以让各种集群在 maintaining strong guarantees 的同时扩展到数以百万计的连接和通道，并且没有一个可以从单个开源供应商处开箱即用。
如果您想使用 Kafka，那么 Redpanda 可能是您应该开始的地方。当您尝试以相对简单的方式处理每条消息时，它们的内嵌 WASM 可能非常有用。 或者你可以使用 Ably ;)