我们正试图评估Kafka并替换我们软件中的Rabbit Mq。
我们知道Kafka在RabbitMq方面的优势，而不是离线消费，巨大的持久性，卓越的性能，低延迟和高吞吐量。
但是，我们需要 RabbitMq 具有的异构消费主题交换粒度路由功能。
在某种程度上，我们可以通过在Kafka中为每个代理提供更多数量的分区来实现这一目标。但它有自己的局限性，例如znode上主题元数据的开销，增加了延迟。
我们的用例是过滤分区内的数据。假设您在一个分区中获取 100 个类似类型的传感器数据。消费者是否有能力只选择少数传感器数据而忽略其余的。
我们可以在应用程序（消费者）端进行过滤/路由，但它似乎不可重用，并且在每个消费者端都有额外的开销。
Kafka有没有办法通过拥有最佳数量的分区来提供丰富的路由功能？
谢谢，阿什什
Kafka的消息传递模型比RabbitMQ简单得多，用户明智地使用它确实提供的一些抽象。实际上，主题是唯一应该在Kafka中完成的路由级别。分区仅用于扩展，提供顺序（但仅在分区内，如果您有一个依赖于顺序的应用程序，这对于可伸缩性来说是一个值得注意的问题），并促进主题内的并发使用者。
在分区级别执行路由的问题在于它是不可扩展的，因为分区是提供可伸缩性的 Kafka 元素（至少在消息传递层）。显然，Kafka 不是为粒度路由而设计的。它专为持久、可靠、可扩展的发布/订阅消息传递而设计。分区也不是设计为跨群集缩放的。就其本质而言，分区是一个或几个 Kafka 节点的本地分区（取决于主题的复制因子），但 Kafka 在集群中将一个主题内的多个分区分散开来。这意味着如果消息偏向于某个特定分区，而不是均匀分布在主题中的分区之间，则存在一些热点的可能性（这就是为什么Kafka生产者通常为您处理分区的原因）。
在客户端的过滤方面，我认为你是对的：这对我来说感觉像是浪费了很多资源，但也许我只是太不喜欢浪费资源了。
简而言之，我认为如果你试图用如此复杂的术语来思考卡夫卡的信息抽象，你可能会把自己挖进一个洞里。Kafka是为通过分区分配负载而设计和优化的，因此将它们用于不同的 （ 即使模糊相似 - 用例肯定不理想。
我有一种感觉，你可以在Kafka的功能上下文中管理你的用例。我发现，在Kafka的主题框架中，复杂路由方案面临的最大挑战是防止多个主题中的重复数据，但是一旦您了解多个应用程序如何从同一主题中的不同位置使用，这个问题似乎就会消失。从这个意义上说，重要的是将 Kafka 视为日志而不是队列。
顺便说一句，我认为您对管理分区所需的znode的担忧是没有根据的。如果您有足够的主题和分区来消耗ZooKeeper节点的内存（一吨），那么您可能已经遇到了更大的资源问题。
