在一個電商平臺系統里,每當客戶下訂單時，你需要：

• 處理支付。
• 更新庫存。
• 發送確認郵件。

在高峰期立即執行所有這些操作，可能會減慢客戶的體驗。

在這種情況下，我們有大量的應用事件，而無法同時處理所有事件。

消息隊列的基本架構

消息隊列是一個持久化組件，存儲在內存中，支持異步通信。它充當緩沖區，并分發異步請求。

消息隊列的基本架構很簡單。輸入服務稱為生產者或發布者，創建并將消息發布到消息隊列。其他服務稱為消費者或訂閱者，連接到隊列并執行消息定義的操作。

在實際場景中，可能有許多應用程序寫入隊列，也有許多服務器從隊列讀取。

回到例子

在我們的案例中，處理每個任務時，可以將其添加到隊列的末尾，然后從這個隊列將它們發送到我們的服務器。

• 訂單已下： 訂單詳細信息放入一條消息中。
• 消息已發送： 消息被添加到隊列中。
• 工作程序處理： 獨立的進程（工作程序）從隊列的前端提取消息并處理任務。

我們的服務器確認已接收并處理一條消息，隊列則將其移除，以免第二次發送。

使用消息隊列的好處

主要優點是我們解耦了這些事件，消息隊列允許我們異步處理這些事件。我們可以將它們排隊，直到可以處理。

使用消息隊列時，當消費者無法處理消息時，生產者可以將消息發布到隊列中。

消費者即使在生產者不可用時也可以從隊列中讀取消息。

另一個很大的好處是它們是持久化的。如果隊列崩潰，數據不會丟失，因為它不存儲在內存中，而是存儲在磁盤上。

如果工作程序在處理消息時崩潰，也沒問題！消息仍在隊列中，將被另一個工作程序提取。

消息隊列還提供了可擴展性。如果接收到大量訂單，隊列會變得更長。你可以添加更多的工作程序來處理額外的負載，而不影響網站。

不同的隊列類型

消息隊列有多種類型。最常見的包括：

• FIFO（先進先出）： 就像一個普通的隊列，消息按照到達的順序處理。這對于支付處理等情況非常重要。
• 優先隊列： 某些消息可能比其他消息更重要。你可以優先處理這些消息。

推送與拉取

一些隊列等待工作程序請求消息（拉取式隊列），而另一些則主動將消息發送給工作程序（推送式隊列）。

示例

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

• RabbitMQ： 一種多用途隊列，適合多種用例。
• Kafka： 為高吞吐量和實時數據流設計，適用于日志記錄和事件驅動架構。
• Amazon SQS（簡單隊列服務）： AWS提供的完全托管的基于云的隊列服務。它可擴展且可靠，具有延遲隊列和死信隊列等功能。