1 Nats

NATS 最初是用 Ruby写的，每秒可处理 15 万条消息。后来 Go 重写了它，现在可以每秒处理上千万条消息。

优点：设计简洁，低功耗，高速通信总线，高可用，高扩展性，轻量级，部署简单。

缺点：即发即忘，没有持久性。如果您处于离线状态，则不会收到消息。没有事务

总的说来NATS 和 Redis 更适合较小的消息（远低于 1MB），其中延迟往往是亚毫秒级。NATS 没有复制、分片或总排序。使用 NATS，队列可以有效地按节点进行分片。如果一个节点死亡，它的消息就会丢失。

2 RabbitMQ：

RabbitMQ 是一个遵循 AMQP 0.9.1 代理定义的消息传递引擎。它遵循标准的存储转发模式，您可以选择将数据存储在 RAM、磁盘或两者中。它支持多种消息路由范例。RabbitMQ 可以以集群方式部署以提高性能，并以镜像方式部署以实现高可用性。消费者直接在队列上收听，但发布者只知道“交换机”。这些交换机通过绑定链接到队列，绑定指定路由范例。RabbitMQ 确实将消息持久化到磁盘。与 NATS 不同，它是一个更传统的消息队列，因为它支持绑定队列和事务传递语义。
因此，RabbitMQ 是一种更“重量级”的队列解决方案，并且倾向于支付额外的费用。

缺点：
RabbitMQ 的高可用性支持很糟糕。无论您如何调整它，它都是单点故障，因为它无法合并由裂脑情况导致的冲突队列。分区不仅会在网络中断时发生，还会在高负载情况下发生。

3 Kafka

使用 Kafka，您可以同时进行实时和批处理。Kafka 在 JVM 上运行（具体来说是 Scala）。摄取大量数据，通过发布-订阅（或排队）进行路由。经纪人对消费者几乎一无所知。真正存储的只是一个“偏移量”值，它指定了消费者在日志中停止的位置。
与许多假定消费者大部分在线的集成代理不同，Kafka 可以成功地保存大量数据并支持“重放”场景。
该架构非常独特；主题被安排在分区中（为了并行），分区被跨节点复制（为了高可用性）。

与 Kafka 相比，NATS 是一个非常小的基础设施。与 Nats 相比，Kafka 更加成熟，并且在海量数据流方面表现非常出色。
NATS 服务器具有 Kafka 中的一部分功能，因为它专注于更窄的用例集。
NATS 专为高性能和低延迟至关重要但丢失一些数据的场景而设计如果需要跟上数据——NATS 文档将其描述为“即发即忘”。在架构上，这是因为 NATS 没有持久层来持久存储数据。
而 Kafka 确实有一个持久层（使用集群上的存储）。
为了完全保证消息不会丢失，看起来您需要将队列声明为持久+将您的消息标记为持久+使用发布者确认。这会花费数百毫秒的延迟。

唯一不会出现分区错误的队列或发布/订阅系统是 Kafka。当你需要 5-50 台服务器时，Kafka 是一个非常可靠的工程。有了那么多服务器，您每秒可以处理数百万条消息，这通常足以满足中型公司的需求。

出于几个原因，Kafka 完全不适合 RPC。首先，它的数据模型将队列分成多个分区，每个分区只能由一个消费者使用。假设我们有分区 1 和 2。P1 是空的，P2 有大量消息。您现在将有一个闲置的消费者 C1，而 C2 正在工作。C1 不能承担 C2 的任何工作，因为它只能处理自己的分区。换句话说：单个慢速消费者可以阻塞队列的很大一部分。Kafka 专为快速（或至少性能均匀）的消费者而设计。

4 NSQ

NSQ 似乎更灵活，它支持消息持久化，并在持久化不是硬性要求时提供类似 NATS 的临时通道。
它带有一个闪亮的管理仪表板，这是 NATS 所缺乏的。当优先考虑原始性能时，NATS 很有用。NATS 和 NSQ 队列都支持每条消息的 TTL，用于修剪对时间敏感的消息。

Kafka 很复杂，但保证不丢失数据。适用于有序日志。NSQ 缺乏持久性和复制性。大规模操作非常简单。Kafka 的性能和附加保证是以更难操作为代价的。使用 Kafka，除了 Kafka 代理之外，您还需要一个 Zookeeper 集群。Kafka 需要考虑分区和偏移量。最好将 Kafka 视为分布式日志服务而不是消息代理，就像数据库中的预写日志而不是 printf 语句。

NSQ 是一个更传统的缓冲消息系统。它具有文件持久性，NSQ 有一个内置实用程序 nsq_to_file，它只是一个额外的消费者，您可以使用它来将每个消息主题存档到磁盘。它提供非常简单的消息归档，但不提供任何本机重播功能。