经验分享:RabbitMQ与Kafka等消息系统的使用者讨论 - ycombinator

20-05-22 banq

vel0city:我已经在相当小的VM上运行RabbitMQ很长时间了。RabbitMQ不需要每条消息大量的资源,即使使用非常小的VM(512MB RAM,单个CPU),我也看到它每秒处理数千条消息的峰值而不会出现问题。给它一些强大的硬件,它可能会处理您正在考虑的任何负载,除非您使10gig链接的消息或其他内容饱和。

考虑扩展性和性能时,RabbitMQ和Kafka非常不同。Kafka几乎是一个通过系统路由的消息数据库。在许多配置中,客户端可能会回来并要求从几乎任何时间点重播消息流。这意味着您需要处理大量的磁盘和内存访问。传统上,使用RabbitMQ,消息是短暂的。确认消息后,消息就消失了。不存在内存中,也不在磁盘上。没有人会再来询问该消息。这样可以提高处理每条消息的效率,但是代价是无法记住几毫秒前通过系统的消息。

addisonj:作为已经在生产环境中运行许多消息传递系统的人,这是我目前的大致看法:

如果您要转向“事件溯源”架构,通常要考虑的两个主要问题(除了正常运行时间,规模等基本操作之外)是路由和长期保存。

RabbitMQ有路由,但没有保存。Kafka 可以保存和路由,但是可能很复杂/昂贵。Apache Pulsar确实在此闪耀,因为该API是pub / sub,但是它的日志结构为您提供了长期保留(无需手动重新平衡),但是灵活性确实伴随着某些操作的复杂性与RabbitMQ相比。

如果您的需求只是移动大量数据,那么Kafka无疑是最成熟的并且拥有庞大的生态系统,但是长期保留很困难,并且在消费者群体中也有一些利器。

如果您确实真的不需要长期保留并且需要复杂的拓扑,RabbitMQ是您的最佳选择,并且即使在相当高的消息速率下运行也相当合理(〜10k msgs/sec应该不太难实现)

但是,如今有更多的选择,更老的Java解决方案(例如activeMQ和rocketMQ)或更多的“最小”实现(例如NAT),更不用说云提供商上的托管服务了。

就个人而言,我是Apache Pulsar的忠实拥护者,因为它具有灵活性和一些不错的设计选择,但我认为在这个领域没有任何灵丹妙药。

atombender:请谨慎购买RabbitMQ的集群。运行了多年之后,我发现它非常脆弱。我们经常丢失整个队列,因为一个小的网络故障使RabbitMQ认为存在网络分区,并且当其他节点变为可见时,RabbitMQ没有可靠的方式将其状态恢复为原来的状态。它有很多技巧可以缓解这种情况,但是它们并不能解决核心问题。可靠运行镜像队列(未称为“经典镜像队列”)的唯一方法是禁用自动恢复,然后每次发生这种情况时都必须手动修复RabbitMQ。如果您关心完整性,则可以使用新的仲裁队列,该队列使用基于Raft的共识系统,但是它们缺少“经典”队列的许多功能。例如,没有消息优先级。

如果您愿意在极高的负载下丢失偶尔出现的消息,则NATS 绝对是奇妙的,而且非常快速且易于集群。另外,NATS Streaming 和Liftbridge是建立在NATS之上的两个消息代理,它们实现了可靠的传递。我没有用过,但听到了好消息。

[1] https://www.rabbitmq.com/partitions.html

[2] https://www.rabbitmq.com/quorum-queues.html

[3] https://nats.io/

[4] https://docs.nats.io/nats-streaming-concepts/intro

[5] https://github.com/liftbridge-io/liftbridge

snapetom:由于三个原因,我最终向往了Rabbit。

  1. 对于中小型体系结构,更容易实现和维护。但是,我听到的故事表明,它开始成为大型集群体系结构的麻烦。
  2. 因为它是传统的消息代理,所以我负责的输入和输出端的编写要简单得多,因为我不必担心重新联机时的重放。Rabbit知道它已经路由到了哪个客户端以及消息的去向。kafka在这方面并不那么复杂。kafka被描述为“愚蠢经纪人/智能客户”,而Rabbit则被描述为“智能经纪人/愚蠢的客户”。
  3. 缩放。Rabbit是非常可扩展的。一旦达到Uber/Paypal级别(例如每秒几百万次写入),那么Kafka便成为显而易见的选择。Rabbit每秒可以处理数千次写入。但是,在第二家公司以及其他许多公司中,他们认为必须吸收所有数据,因此,从长远来看,Kafka当然是更具扩展性的工具。剧透:我们从来没有接近PayPal级交易。

更多信息点击标题。

 

              

1
猜你喜欢