Kafka 与其他消息系统对比

Apache Kafka

尽管Apache Kafka最初被设计为消息队列，但该软件迅速发展成为一种事件流平台，如今每天处理数十亿个事件。在任何需要消息队列或消息代理系统的地方，Kafka都是一个理想的选择。

特性

1. 与消息系统或消息队列系统类似，Apache Kafka支持发布和订阅记录流。
2. 记录流采用容错机制进行存储。
3. 具备可扩展性，能够实现应用间的解耦。
4. 易于使用且高可用。
5. 提供高吞吐量，适用于实时数据传输。

为什么选择Kafka？

使用Kafka的主要优势在于其通过分区实现主题的并行化处理能力，每个分区可以部署在不同的机器上。消费者可以并行访问主题。同时允许多个消费者访问多个分区，从而更轻松地实现扩展。这一独特特性显著提升了Kafka在处理消息队列时的吞吐量。

Kafka出色的扩展能力使其能够应对大规模工作负载。例如，LinkedIn每天利用Kafka管理3000亿条用户事件。

在实时数据管道场景中，Kafka通常比其他消息队列更受青睐。总体而言，它是一个多功能平台，可支持多种应用场景，包括数据流处理、消息代理系统、日志聚合等。

ActiveMQ

Apache ActiveMQ 是一款用 Java 编写的流行开源消息服务。它最初由 LogicBlaze 于 2004 年开发为开源消息代理，并于 2007 年捐赠给 Apache 软件基金会。

与其他消息代理一样，它作为运行在不同服务器上或使用不同编程语言编写的应用程序之间的通信平台。它实现了 JMS（Java 消息服务），并支持 AMQP 和 MQTT 等多种消息协议。

特性

1. 支持多种连接协议。
2. 可安排延迟投递消息，这是 Kafka 不具备的功能。
3. 使用数据库行级锁、文件系统及其他模式来保障高可用性。
4. 除了基本认证和 JAAS 认证外，还提供自定义认证插件的 API。
5. 支持垂直扩展，也内置了水平扩展功能（称为“代理网络”）。
6. 支持多种传输协议，包括 STOMP、REST 和 OpenWire。

为什么选择 ActiveMQ？

ActiveMQ 是分布式系统中广泛使用的消息服务。与能够处理海量数据的 Kafka 不同，ActiveMQ 更适合处理少量数据的场景。

在 ActiveMQ 中，消息可以以队列形式或主题形式发送。点对点消息传递中，一个或多个消费者连接到队列，代理使用轮询方式将消息分发给特定消费者。在基于订阅的消息传递中，代理会将消息广播给所有订阅该主题的消费者。

相比 Kafka 及其他服务，当应用涉及复杂的消息路由时，ActiveMQ 是一个合适的选择。虽然其吞吐量不高，并且随着并发客户端数量和存储数据量的增加而下降，但对于大多数不需要大数据处理的企业来说，ActiveMQ 非常适用。

RabbitMQ

RabbitMQ 是另一款广泛使用的开源消息代理，被全球多家公司采用。它使用 Erlang 编写，最初专为高级消息队列协议（AMQP）设计，现已更新支持 STOMP 和 MQTT 等其他协议。

特性

1. 支持多种消息传递方式，包括发布/订阅、点对点以及请求/响应模式。你还可以编写自己的消息机制并作为插件使用。
2. 支持同步和异步两种通信模式。
3. 消息确认机制确保服务的可靠性。
4. 通过在集群的多个节点之间复制队列，实现高可用性，即使发生硬件故障也不会丢失消息。
5. 提供管理界面，便于用户友好地控制和监控消息代理的各项功能。

为什么选择 RabbitMQ？

得益于对复杂路由的支持，RabbitMQ 被众多大型企业采用，包括 NASA。在对消息安全性要求较高的应用中，它通常是首选方案。无论你是希望对消息有更强的控制权，还是想将消息队列系统集成到现有架构中，RabbitMQ 都是不错的选择。它提供多种内置插件，同时也支持自定义插件。

尽管该服务具有良好的可移植性、可靠性和易用性，但在可扩展性方面不如其他消息代理。镜像机制带来的开销以及中心节点产生的延迟，显著降低了 RabbitMQ 的吞吐量。

Amazon SNS

Amazon SNS（Amazon Simple Notification Service）是亚马逊提供的推送通知服务。它可以向大量客户发送单条消息或广播消息，主要面向移动设备。支持向 Kindle Fire、百度等多种平台发送消息，也可用于其他分布式系统。

特性

1. 借助 AWS 云自动扩展工作负载，可随应用规模提升而应对更高吞吐量。
2. 可向超过 200 个国家的客户发送短信。
3. 支持多种移动平台，包括 Apple、Android 和电子邮件（SMTP）。发送方可通过单一代码接口跨多个平台推送消息。
4. 发送方可创建死信队列，用于存储未能送达订阅端点的消息。
5. 支持消息过滤，订阅者仅接收与其兴趣相关的消息，而非全部发布的消息。
6. 通过 Amazon CloudWatch，可查看系统指标并快速定位和解决问题。

为什么选择 Amazon SNS？

它是一种低成本基础设施，主要用于企业向客户发送发布/订阅类型的消息。这项 Web 服务使发布者能轻松从云端创建并推送通知，提供灵活的消息发布与分发方式。对于希望快速集成、维护成本低且采用按需付费模式的开发者而言，SNS 是理想选择。

然而，它并不适用于点对点或请求/响应式消息传递。如果你的应用需要更丰富的消息类型，传统消息队列系统更为合适。除非你的应用需要传统的队列机制，否则 Amazon SNS 是向客户推送订阅消息的更经济方案。相比 ActiveMQ 或其他标准消息队列系统，SNS 的扩展更加容易。

Amazon SQS

Amazon SQS 是亚马逊自 2004 年起提供的完全托管分布式消息队列服务。它是一种成本效益高且简单的技术，用于管理运行在云环境中的软件系统各组件之间的通信。

特性

1. SQS 队列可根据工作负载自动扩展。
2. 使用 Amazon SQS 无需额外基础设施。
3. 提供有限数量的消息队列免费套餐。随着需求增长，仅需为实际读取和写入的消息付费。
4. 可选择标准队列或 FIFO 队列。
5. FIFO 队列确保消息按发送顺序精确一次交付，在某些关键应用中具有重要意义。
6. 未处理的消息可存入死信队列。

为什么选择 Amazon SQS？

Amazon SQS 对于无服务器架构尤为重要，尤其当你希望不同服务独立运行时。它为这些解耦的服务提供了轻量级且高效的通信方式。特别适用于运行在 AWS 上的无服务器应用，因为 SQS 本身也在 AWS 内部运行，从而提高网络吞吐量并降低延迟。

Amazon SQS 提供两个 API 端点：一个用于发送消息，另一个用于从队列接收消息。每个端点可同时支持多个客户端。在需要集成多个独立系统的应用中，SQS 是理想选择，因为它保证了精确一次交付，并支持队列两端的多连接。不过，FIFO 队列的吞吐量有限，因此不适合广播类消息场景。

Google Pub/Sub

Google Cloud Pub/Sub 是一种异步消息服务，用于在独立应用程序之间发送和接收消息。它提供可靠的消息存储和低延迟的消息传递，是开发者在分发事件通知、从各类设备流式传输数据或实现异步工作流时的首选。

特性

1. 低延迟和高吞吐量。
2. 支持推送和拉取两种消息传递方式。
3. 每条消息均存储在多台服务器上，确保至少一次投递。
4. 具有高度可扩展性，默认支持每秒 10,000 条消息，如需更多可申请扩容。
5. 消息在传输和存储过程中均进行加密，保障数据安全。
6. 前 10GB 数据传输免费。

为什么选择 Google Pub/Sub？

Google Pub/Sub 提供跨互联网任意位置部署的应用之间的可靠消息传递与数据流服务，尤其适用于 Google Cloud Platform 上的应用。它包含多项高级功能，简化了通信管理。自动扩展、死信投递和消息过滤等功能让应用更易维护。许多开发者青睐其灵活的计费模式——在前 10GB 免费后，按传输的数据量收费。

如果你正在寻找消息代理，RabbitMQ 在速度方面可能更具优势，但 Google Pub/Sub 在安全性方面表现更佳。对于已在 Google Cloud Platform 上运行应用的用户，推荐使用 Google Pub/Sub，因为它能与现有应用无缝集成。