gpt4 book ai didi

java - 我们能否拥有类似于 RabbitMq 的 Apache Kafka 强大的路由能力?

转载 作者:IT老高 更新时间:2023-10-28 21:01:37 25 4
gpt4 key购买 nike

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

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

但我们需要像 RabbitMq 那样具有主题交换粒度路由的能力,以实现异构消费。

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

我们的用例是过滤分区内的数据。假设您在一个分区中获得 100 个类似类型的传感器数据。消费者是否可以只选择少数传感器数据而忽略其余数据。

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

Kafka 有没有什么办法可以通过优化分区数来提供丰富的路由能力?

谢谢,阿什什

最佳答案

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

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

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

简而言之,如果您尝试以如此复杂的术语来考虑 Kafka 的消息传递抽象,我认为您可能会冒着自掘坟墓的风险。 Kafka 非常专为通过分区分配负载而设计和优化,因此将它们用于不同的 - 即使是模糊相似的 - 用例当然不是理想的。

我感觉您可以在 Kafka 的功能范围内管理您的用例。我发现 Kafka 主题框架中复杂路由方案的最大挑战是防止多个主题中的重复数据,但是一旦您了解了多个应用程序如何从同一主题中的不同位置消费,这个问题似乎就消失了。从这个意义上说,将 Kafka 更多地视为日志而不是队列是很重要的。

附带说明,我认为您对管理分区所需的 znode 的担忧是没有根据的。如果您有足够的主题和分区来消耗 ZooKeeper 节点的内存(一吨),那么您可能已经遇到了更大的资源问题。

关于java - 我们能否拥有类似于 RabbitMq 的 Apache Kafka 强大的路由能力?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/29272128/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com