什么是消息隊列?

消息隊列的實際定義是一個用于進程間通信的組件，它將控制、內容或消息傳遞給另一個組件。

以另一種方式說明消息隊列，將其視為在您最喜歡的餐廳訂購。一線工作人員會為您點單，準備您最喜歡的餐點。然后，前線工作人員向廚房請求您的食物。廚房接受訂單并制作食物。在這種情況下，收到指令并執行觸發事件的操作 - 執行 訂單、觸發請求、執行操作。

在廚房為您制作食物時，一線工作人員不會等到食物出現，他們會繼續接受其他顧客的訂單。廚房繼續通過訂單運作和處理。每個點都有自己的職責，不會等待對方完成他們正在做的事情，也不受時間的限制。

消息隊列用例

現在您可能會想，“消息隊列到底適合我的架構哪里”?簡單快捷的答案是：

由于同時請求過多，您會遇到“超時錯誤”。

您需要一種解耦方式在應用程序之間或應用程序內進行通信。

您輪詢數據存儲過于頻繁，并且您希望該數據存儲可用于回答符合條件的查詢

您需要在高峰時段擴大和縮小規模

換句話說，任何時候任務不是基本用戶事務的一部分，和/或結果不影響用戶響應，這對于消息隊列來說都是一項完美的工作。

消息隊列也可用于更高級的場景。例如，可以將基于 AMQP 的消息隊列(如 RabbitMQ)配置為根據規則和替代流程路由和分發消息。處理系統可能會花時間處理消息。當業務和工作負載增長并且需要擴展系統的需求很明顯時，添加更多的消費者來處理隊列既快速又容易。

我們現在將解釋消息隊列可以帶來好處的情況。簡單地說，兩個明顯的例子可以作為消息隊列真正閃耀的例子：

對于長時間運行的進程和后臺作業

作為微服務之間的中間人

長時間運行的進程和后臺作業

當請求花費大量時間時，合并消息隊列是完美的方案。

想象一個每秒處理多個請求并且在任何情況下都不會丟失一個請求的 Web 服務。此外，請求是通過耗時的過程處理的，但系統不能陷入困境。一些現實生活中的例子可能包括：

圖像縮放

發送大量/大量電子郵件

搜索引擎索引

文件掃描

視頻編碼

傳遞通知

PDF處理

計算

微服務之間的中間人

對于應用程序內部和應用程序之間的通信和集成，即作為微服務之間的中間人，消息隊列也很有用。想象一個系統，它需要通知系統的另一部分開始處理一項任務，或者當有大量請求同時進入時，如下面的場景：

訂單處理(下訂單、更新訂單狀態、發送訂單、付款等)

送餐服務(下單、準備訂單、送餐)

任何需要處理多個請求的 Web 服務

圖像縮放

讓我們從公司需要縮放圖像的用例開始。

在房地產領域，經紀人需要大量照片才能有效地推銷房產并吸引買家的眼球。通過該平臺，一旦經紀人添加了該財產的新圖像，將其縮放到用戶友好大小的任務就交給了 RabbitMQ。消息隊列一直執行圖像縮放任務，直到消費者抓取它、縮放它，然后以新的有效尺寸將圖像發布到網站。

但是為什么要在這種情況下使用消息隊列呢?僅僅是因為可能同時添加了許多圖像，這可能會導致系統縮放部分出現超時錯誤。

Hemnet 是一個房產上市平臺，在不到一年的時間內從完全內部部署的解決方案轉變為一個新的基于云的解決方案。

從單體到微服務

作為增長最快的數字停車服務之一，Parkster 已將其單體架構分解為更快、解耦的微服務。與 Netflix 一樣，Parkster 最初也是作為一個整體來證明其商業模式的。他們很快意識到這種類型的系統——將整個應用程序構建到一個單元中，具有一個代碼庫和一個系統——效率不高。

公司成立幾年后，Parkster 開始將整體拆分為多個通過消息隊列進行通信的小型微服務。

文件掃描

Softonic 是軟件和應用程序發現門戶，每月擁有超過 1 億用戶，每天下載量超過 200 萬次。該門戶在其提供的服務之間具有恒定的事件和命令流，而 RabbitMQ 是首選的消息隊列，有助于 Softonic 以快速、有效的架構而聞名。

用戶將文件上傳到 Softonic 平臺，在那里進行病毒掃描，并在分發給其他用戶之前收集有關文件的信息。上傳成功后立即通知用戶。文件信息以新的二進制數據的形式存在于一個專用服務上，并向消息隊列發送通知，告知其他服務有數據準備就緒。其他服務處理這些數據，這些數據是持久的，并在過程結束時添加到網站。

以Softonic平臺為例，RabbitMQ的微服務架構使得Web服務器能夠快速響應請求，而不是被迫在現場執行資源繁重的流程，這對用戶體驗來說是不利的。

PDF處理

Web 應用程序允許用戶將信息上傳到網站。該站點將處理此信息并生成 PDF 并將其通過電子郵件發送給用戶。在本例中，處理信息、生成 PDF 和發送電子郵件將花費幾秒鐘，這也是使用消息隊列的原因之一。

在服務器后臺工作人員之間傳遞后臺消息

FarmBot 是一種開源機器人硬件套件，能夠以高效、有趣的方式與農業項目進行交互。FarmBot 采用物理傳感器和執行器，需要物理花園和軟件之間的通信方法。

遠程過程調用或 HTTP 請求/響應模式并不總是適用于 FarmBot，在這種情況下，設備可能被迫執行長輪詢活動，并不斷向 API 發出任何新遠程過程調用的請求。這將導致 Web 應用程序出現巨大的可擴展性問題，并導致用戶的實時體驗低于標準。

例如，當 FarmBot 收到緊急停止消息時，應在創建后立即收到，而不是要求系統不斷檢查 API。其他示例包括遠程過程調用和實時數據同步。

消息隊列現在是 FarmBot Web API 的一個重要組件，用于處理各種任務，包括：

在用戶和設備之間傳遞推送通知

在服務器后臺工作人員之間傳遞后臺消息

通過一組自定義授權插件防止未經授權的使用

使用的消息隊列是RabbitMQ，一個實時消息代理，所以不需要檢查新消息。諸如用戶單擊界面上的“移動”按鈕之類的消息在客戶端、設備和服務器之間來回發送，不需要請求。

將消息代理視為機器對機器的聊天應用程序。任何具有正確授權的軟件包，包括 REST API、FarmBot OS 或第三方固件，都可以向當前連接到消息代理的任何其他實體發送消息。

ElephantSQL(PostgreSQL 數據庫托管服務)的數據庫備份處理

ElephantSQL(PostgreSQL 數據庫即服務)在架構中使用隊列進行日常備份處理。每天有數千條“執行-數據庫-備份”消息添加到隊列中，每個數據庫一個。然后另一個服務訂閱消息并創建備份。

也可以通過客戶 API 或 Web 界面按需創建備份。這個備份應該在請求發送后立即可用 - 換句話說，這是一個優先事項。為了解決這個問題，你的消息隊列需要能夠以某種方式對消息進行優先級排序，在這種情況下使用 RabbitMQ。“perform-database-backup”消息被添加到同一個隊列中，但該消息的消息優先級高于所有其他請求。發送的消息將立即放在隊列的頭部。

使用消息隊列擴展微服務架構

CloudAMQP(RabbitMQ 即服務)由許多提供各種功能的消息隊列提供支持。如果您對此比較感興趣，想了解更多相關知識，不妨來關注一下動力節點的Java在線學習，里面課程內容豐富，通俗易懂，適合沒有基礎的小伙伴學習，希望對大家能夠有所幫助。