在一个电商平台系统里,每当客户下订单时，你需要：
- 处理支付。
- 更新库存。
- 发送确认邮件。
在高峰期立即执行所有这些操作，可能会减慢客户的体验。
在这种情况下，我们有大量的应用事件，而无法同时处理所有事件。
消息队列的基本架构
消息队列是一个持久化组件，存储在内存中，支持异步通信。它充当缓冲区，并分发异步请求。
消息队列的基本架构很简单。输入服务称为生产者或发布者，创建并将消息发布到消息队列。其他服务称为消费者或订阅者，连接到队列并执行消息定义的操作。
在实际场景中，可能有许多应用程序写入队列，也有许多服务器从队列读取。
回到例子
在我们的案例中，处理每个任务时，可以将其添加到队列的末尾，然后从这个队列将它们发送到我们的服务器。
- 订单已下： 订单详细信息放入一条消息中。
- 消息已发送： 消息被添加到队列中。
- 工作程序处理： 独立的进程（工作程序）从队列的前端提取消息并处理任务。
我们的服务器确认已接收并处理一条消息，队列则将其移除，以免第二次发送。
使用消息队列的好处
主要优点是我们解耦了这些事件，消息队列允许我们异步处理这些事件。我们可以将它们排队，直到可以处理。
使用消息队列时，当消费者无法处理消息时，生产者可以将消息发布到队列中。
消费者即使在生产者不可用时也可以从队列中读取消息。
另一个很大的好处是它们是持久化的。如果队列崩溃，数据不会丢失，因为它不存储在内存中，而是存储在磁盘上。
如果工作程序在处理消息时崩溃，也没问题！消息仍在队列中，将被另一个工作程序提取。
消息队列还提供了可扩展性。如果接收到大量订单，队列会变得更长。你可以添加更多的工作程序来处理额外的负载，而不影响网站。
不同的队列类型
消息队列有多种类型。最常见的包括：
- FIFO（先进先出）： 就像一个普通的队列，消息按照到达的顺序处理。这对于支付处理等情况非常重要。
- 优先队列： 某些消息可能比其他消息更重要。你可以优先处理这些消息。
推送与拉取
一些队列等待工作程序请求消息（拉取式队列），而另一些则主动将消息发送给工作程序（推送式队列）。
示例
以下是一些流行的消息队列示例：
- RabbitMQ： 一种多用途队列，适合多种用例。
- Kafka： 为高吞吐量和实时数据流设计，适用于日志记录和事件驱动架构。
- Amazon SQS（简单队列服务）： AWS提供的完全托管的基于云的队列服务。它可扩展且可靠，具有延迟队列和死信队列等功能。
