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