本文为各位开发者、架构师讲述系统设计中的消息队列，场景，设计与实践。

想象一下一个在线商店，每次客户下订单时，我们都需要：

• 处理付款。

• 更新库存。

• 发送确认电子邮件、短信等。

立即执行所有这些操作，尤其是在流量高峰期，可能会降低客户的体验。在这种情况下，有大量的应用程序事件，我们无法一次处理所有事件。

当然，我们可以扩展服务器来处理这些大量的应用程序事件，但如果不用一次处理所有事件，那么最好将这些事件排队并稍后处理。

消息队列的基本架构

消息队列是存储在内存中、支持异步通信的持久化组件，起到缓冲区的作用，分发异步请求。

消息队列的基本架构很简单。

输入服务（称为生产者或发布者）创建消息并将其发布到消息队列。其他服务（称为消费者或订阅者）连接到队列并执行消息定义的操作。

在现实世界中，可能有许多应用程序写入队列，也有许多服务器从队列读取。

回到例子

因此在例子中，我们不必立即处理每个任务，而是可以将其添加到队列的后面，然后从这个队列将它们发送到我们的服务器。

• 已下订单：订单详情已放入消息中。

• 消息已发送：消息已添加到队列。

• 工作进程：单独的进程（Workers，工作者）从队列前面拉取消息并处理任务。

此外，我们的服务器确认它已收到并处理了一条消息，然后队列会将其删除，以便不会再次发送。

使用消息队列的好处

队列的主要优点是我们可以将这些事件解耦，并且这个消息队列将允许开发者异步处理这些事件。

我们可以将它们排队，直到到达我们可以处理它们为止。

有了消息队列，当消费者无法处理消息时，生产者可以向队列发布消息。

此外，即使生产者不可用，消费者也可以从队列中读取消息。

另一个特别大的好处是它们非常耐用。如果队列崩溃，数据不会丢失，因为它不是存储在内存，而是存储在磁盘中。

如果某个 worker 在处理消息时崩溃了，也没有问题！消息仍在队列中，将由另一个 worker 接收。

消息队列还提供可扩展性。如果您收到大量订单，队列只会变得更长一些。您可以添加更多worker来处理额外的负载，而不会影响网站。

不同的队列类型

消息队列有多种类型。最常见的有：

• FIFO（先进先出）：与普通线路一样，消息按到达的顺序进行处理。这对于付款处理等而言非常重要。

• 优先级队列：某些消息可能比其他消息更重要。您可以对这些消息进行优先级排序，以便更快地处理它们。

推与拉

一些队列等待工作者请求消息（基于拉的队列），而其他队列主动向工作者发送消息（基于推的队列）。

示例

以下是一些流行的消息队列示例：

• RabbitMQ：一种适用于多种用例的多功能队列。

• Kafka：专为高吞吐量和实时数据流而构建。非常适合日志记录和事件驱动架构等。

• Amazon SQS（简单队列服务）：AWS 提供的完全托管的基于云的队列服务。它具有可扩展性和可靠性，具有延迟队列和死信队列等功能。

关于消息队列，各位有何看法？欢迎留言讨论～

作者：万能的大雄