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