聊一聊系統(tǒng)設計中的消息隊列
在一個電商平臺系統(tǒng)里,每當客戶下訂單時,你需要:
- 處理支付。
- 更新庫存。
- 發(fā)送確認郵件。
在高峰期立即執(zhí)行所有這些操作,可能會減慢客戶的體驗。
在這種情況下,我們有大量的應用事件,而無法同時處理所有事件。
消息隊列的基本架構
消息隊列是一個持久化組件,存儲在內存中,支持異步通信。它充當緩沖區(qū),并分發(fā)異步請求。
消息隊列的基本架構很簡單。輸入服務稱為生產者或發(fā)布者,創(chuàng)建并將消息發(fā)布到消息隊列。其他服務稱為消費者或訂閱者,連接到隊列并執(zhí)行消息定義的操作。
在實際場景中,可能有許多應用程序寫入隊列,也有許多服務器從隊列讀取。
回到例子
在我們的案例中,處理每個任務時,可以將其添加到隊列的末尾,然后從這個隊列將它們發(fā)送到我們的服務器。
- 訂單已下: 訂單詳細信息放入一條消息中。
- 消息已發(fā)送: 消息被添加到隊列中。
- 工作程序處理: 獨立的進程(工作程序)從隊列的前端提取消息并處理任務。
我們的服務器確認已接收并處理一條消息,隊列則將其移除,以免第二次發(fā)送。
使用消息隊列的好處
主要優(yōu)點是我們解耦了這些事件,消息隊列允許我們異步處理這些事件。我們可以將它們排隊,直到可以處理。
使用消息隊列時,當消費者無法處理消息時,生產者可以將消息發(fā)布到隊列中。
消費者即使在生產者不可用時也可以從隊列中讀取消息。
另一個很大的好處是它們是持久化的。如果隊列崩潰,數(shù)據(jù)不會丟失,因為它不存儲在內存中,而是存儲在磁盤上。
如果工作程序在處理消息時崩潰,也沒問題!消息仍在隊列中,將被另一個工作程序提取。
消息隊列還提供了可擴展性。如果接收到大量訂單,隊列會變得更長。你可以添加更多的工作程序來處理額外的負載,而不影響網(wǎng)站。
不同的隊列類型
消息隊列有多種類型。最常見的包括:
- FIFO(先進先出): 就像一個普通的隊列,消息按照到達的順序處理。這對于支付處理等情況非常重要。
- 優(yōu)先隊列: 某些消息可能比其他消息更重要。你可以優(yōu)先處理這些消息。
推送與拉取
一些隊列等待工作程序請求消息(拉取式隊列),而另一些則主動將消息發(fā)送給工作程序(推送式隊列)。
示例
以下是一些流行的消息隊列示例:
- RabbitMQ: 一種多用途隊列,適合多種用例。
- Kafka: 為高吞吐量和實時數(shù)據(jù)流設計,適用于日志記錄和事件驅動架構。
- Amazon SQS(簡單隊列服務): AWS提供的完全托管的基于云的隊列服務。它可擴展且可靠,具有延遲隊列和死信隊列等功能。