与RabbitMq类似,ApacheKafka能否拥有强大的路由功能？

我们正在尝试评估Kafka并在我们的软件中替换Rabbit Mq.

我们知道Kafka在RabbitMq方面优于离线消费,巨大的持久性,卓越的性能,低延迟和高吞吐量.

但我们需要像RabbitMq一样的功能,使用主题交换粒度路由进行异构消费.

在某种程度上,我们可以通过在Kafka中为每个代理提供更多的分区来实现这一目标.但它有自己的局限性,例如znode上主题元数据的开销,增加延迟.

我们的用例是过滤分区内的数据.假设您在一个分区中获得了100个类似类型的传感器数据.消费者是否有能力仅选择少量传感器数据而忽略其余数据.

我们可以在应用程序(消费者)方面进行过滤/路由,但它似乎不是可重用的,并且在每个消费者方面都有额外的开销.

Kafka有没有办法通过最佳分区数提供丰富的路由功能？

谢谢,Ashish

Kafka的消息模型比RabbitMQ模型简单得多,用户明智地使用它提供的少量抽象.实际上,主题是在Kafka中应该完成的唯一路由级别.分区仅用于扩展,提供顺序(但仅限于分区内,如果您具有依赖于订单的应用程序,这是可扩展性的显着问题),并促进主题中的并发使用者.

在分区级别进行路由的问题在于它不可伸缩,因为分区是提供可伸缩性的Kafka的元素(至少在消息传递层).显然,Kafka不是为粒度路由而设计的.它专为持久,可靠,可扩展的发布/订阅消息传递而设计.分区也不是为了在整个集群中扩展而设计的.就其本质而言,分区是一个或几个Kafka节点的本地(取决于主题的复制因子),但Kafka在群集中的主题内分布多个分区.这意味着如果消息支持某个特定分区而不是在主题中的分区之间均匀分布,则存在一些热点定位的可能性(这就是Kafka生产者通常为您处理分区的原因).

在客户端的过滤方面,我认为你是对的:对我来说感觉就像浪费了很多资源,但也许我只是不喜欢浪费资源.

简而言之,如果你试图用如此复杂的术语来考虑Kafka的消息传递抽象,我认为你可能冒险将自己挖到一个漏洞中.Kafka非常适合并通过分区进行优化以分配负载,因此将它们用于不同的 - 即使是模糊相似的 - 用例肯定不是理想的.

我有一种感觉,你可以在Kafka的功能环境中管理你的用例.我发现Kafka主题框架中复杂路由方案面临的最大挑战是阻止多个主题中的重复数据,但是一旦了解了多个应用程序如何在同一主题中的不同位置消耗,问题似乎就会消失.从这个意义上讲,将Kafka更多地视为日志而不是队列是很重要的.

另外,我认为您对管理分区所需的znodes的关注是没有根据的.如果你有足够的主题和分区来消耗ZooKeeper节点的内存(一吨)那么你可能已经遇到了更大的资源问题.