Message Queues vs Event Streams 消息队列和事件流

原文链接 ：Message Queues vs Event Streams in System Design - GeeksforGeeks

目录

Message Queues

Message Queues的主要特征：

Message Queues常见实现：

Message Queues使用场景

Event streams 

Event Streams的主要特征：

Event Streams常见实现：

Event Streams使用场景

两者不同

---

Message Queues

相当于一个临时存储消息的地方，直到被接收系统或应用组件处理。

Message Queues的主要特征：

1，异步通信

        Message Queues不需要sender 和 receiver同时在线，提供了更灵活和扩展的系统设计。

2，消息持久性

        消息存放在队列中，直到被成功处理。确保了消息不会因为receiver不可用而丢失。

3，负载均衡

        可接多个consumer，Message Queues可以帮助均匀分布消息，以提升系统整体吞吐量。

Message Queues常见实现：

RabbitMQ：一种广泛使用的开源消息代理，支持各种消息传递协议。

Apache ActiveMQ：一个开源消息代理，提供消息传递和集成模式的功能。

Amazon SQS：AWS提供的完全托管的消息队列服务，以其可扩展性和易用性而闻名。

Message Queues使用场景

1，后台Job处理（Background Job Processing）：

        RabbitMQ和Amazon SQS等系统通常用于处理后台任务，例如处理用户请求或异步执行耗时的操作。

2，任务安排（Task Scheduling）：

        消息队列可以安排和管理需要在特定时间或间隔执行的任务，例如发送通知或执行数据备份。

3，订单处理系统（Order Processing Systems）

        在电子商务中，消息队列通过确保每个订单都得到可靠和顺序的处理来管理订单，即使在高流量时段也是如此。

4，微服务通信（Microservices Communication）

        在微服务架构中，消息队列促进了服务之间的通信，使它们能够独立运行并优雅地处理故障。

Event streams 

指实时捕获、处理和使用的连续事件流。强调数据的实时、顺序流。而Message Queues处理的是互不相连的（discrete）消息。

Event Streams的主要特征：

1，实时处理

        Event streams是为需要实时数据处理和分析的场景而设计的。这对于需要在事件发生时对其做出反应的应用程序特别有用。

2，事件源模式

        Event streams通常支持事件源模式(event sourcing pattern)，其中状态变化被捕获为一系列不可变事件。这允许在任何时间点重放和重建系统状态。

3，可扩展性

        Event streams platform 通常用于处理高吞吐量场景，高效处理大量事件。

Event Streams常见实现：

Apache Kafka: 一个以高吞吐量和容错能力而闻名的分布式事件流平台。

Amazon Kinesis: AWS提供的用于实时数据流和分析的托管服务。

Apache Pulsar: 一个专为高吞吐量和低延迟用例设计的云原生( cloud-native)事件流平台。

Event Streams使用场景

1，实时分析（Real-Time Analytics）

        Kafka等事件流用于实时处理和分析大量数据，例如监控用户行为或金融交易。

2，事件源（Event Sourcing）

        在事件驱动的架构中，事件流提供了一种方法，可以将系统状态的变化捕获并存储为一系列不可变事件，从而实现准确的回放和审计。

3，日志聚合（Log Aggregation）

        事件流将来自不同来源的日志聚合到一个中央存储库中，以进行实时分析和监控。

4，欺诈检测（Fraud Detection）

        金融机构通过实时分析交易数据中的模式，使用事件流来检测和应对欺诈活动。

两者不同

功能	message queues	event streams
主要用例	任务分配（Task distribution）和异步通信。	实时数据处理和事件驱动（event-driven）架构。
消息传递	通常保证每条消息 只传递一次（exactly once ） 或至少一次（at least once）。	通常侧重于高吞吐量、低延迟， 并可能涉及“至少一次（at least once）” 或“最多一次（at most once）”的交付语义。
消息顺序	确保单个队列中的消息顺序。	可以确保a partition or stream 的顺序， 但可能无法保证全局（global）顺序。
消费者模式	消息由一个消费者消费并从队列中删除。	事件通常由多个订阅者消费；流仍然可用于回放。
消息持久化	消息通常会被持久化， 直到被使用或过期。	事件通常作为不可变日志的一部分进行持久化。
回放能力	通常不是为重播而设计的；一旦被使用，消息通常就会消失。	专为回放而设计；事件可以从流的开头重新读取或处理。
扩展性	可扩展性可以通过添加更多队列或消费者来实现。	可扩展性通常是通过对流进行分区并在多个消费者之间分布分区来实现的。
状态管理（State Management）	通常需要额外的机制来管理状态和跟踪进度。	状态管理通常内置于事件处理系统中。
延迟	消息传递的延迟通常较低。	可以支持非常低的事件摄取（ingestion） 和处理延迟。