消息隊列

在計算機科學中，消息隊列和郵箱是用於進程間通訊或同一進程內的線程間通訊的軟件工程組件。他們使用一個隊列來傳播消息——傳遞控制或者內容。羣體傳播系統提供相似的功能。

 

概述

 

消息隊列提供一個異步通訊協議，這意味着該消息的發送者和接收者不須要在同一時間與消息隊列進行交互。消息被放入隊列保存，直到接收方處理他們。消息隊列對於一條消息中傳輸的數據大小有顯示或隱式的限制，這樣隊列中才能保持良好的的消息數量。

消息隊列的不少功能由內部實現：在操做系統或應用程序內部。這種隊列的存在只爲運行於該系統。

其餘實現容許不一樣的計算機系統之間傳遞消息，可能會鏈接多個應用程序和多個操做系統。這些消息隊列系統一般提供加強的彈性功能，以確保系統故障時消息不會「丟失」。這種消息隊列軟件（也被稱爲面向消息中間件）的商業實現的例子包括IBM的WebSphere MQ（MQ系列）和Oracle高級隊列（AQ）。Java標準中的Java消息服務（JMS），有幾個專有軟件和免費軟件實現。

各類實現有專有軟件，提供消息隊列服務，開源軟件，或者是基於硬件。

專有選項擁有最長的歷史，包括從一開始的消息隊列產品，如IBM的WebSphere MQ（MQ系列 ），還有依賴特定操做系統的，如Microsoft消息隊列 。

消息隊列服務選項，如StormMQ或IronIO。

有不少開放源碼選項的消息中間件系統，包括JBoss Messaging，JORAM，Apache ActiveMQ，Sun Open Message Queue，Apache Qpid，[8] RabbitMQ，Beanstalk’d，Tarantool和HTTPSQS [9]

除了開源系統，基於硬件的消息中間件的存在有供應商如Solace系統 ，Sonoa / Apigee和Tervela經過硅或硅/軟件數據通路提供隊列。

大多數RTOS鼓勵使用消息隊列做爲主要的IPC或線程間通訊機制，如VxWorks和QNX操做系統。致使消息傳遞與CPU調度緊密集成的主要緣由是RTOS實時應用程序的可用性。早期的商用的RTOS例子鼓勵消息隊列基於線程間通訊，包括VRTX和pSOS +，可追溯至20世紀80年代初。

使用

在典型消息隊列實現中，系統管理員安裝配置現成的消息隊列軟件（隊列管理器或中介），並定義一個命名的消息隊列。或者註冊一個消息隊列服務 。

而後，應用程序註冊一個軟件例程，來「監聽」放入隊列的消息。

後續的應用程序能夠鏈接到隊列並轉移其中的消息。

隊列管理器軟件存儲消息，直到接收應用程序鏈接後調用註冊的軟件例程。而後，接收應用程序以適當的方式處理該消息。

一般有許多選項做爲消息傳遞的精確語義，包括：

• 持久性 – 消息可能被保存在內存中，寫入到磁盤，或甚至提交到DBMS，若是可靠性要求代表了更加資源密集型的解決方案。
• 安全策略 – 哪些應用程序能夠訪問這些消息？
• 消息清理策略 – 隊列或消息應當有存活時間
• 消息過濾 – 一些系統支持過濾數據，所以，訂閱者只能看到匹配預約義興趣標準的消息
• 交付策略 – 咱們是否是應該保證消息傳遞至少一次，或不超過一次？
• 路由策略 – 在一個有許多隊列服務器的系統中，哪些服務器應該收到一條消息或一隊列的消息？
• 批量策略 – 是否當即將消息傳送？仍是說系統應該稍等，並嘗試一次傳遞多條消息？
• 排隊標準 – 何時應當考慮消息「入隊」？何時隊列有了？或者，什麼時候它被轉發到至少一個遠程隊列？或全部隊列？
• 已收通知 – 發佈者可能須要知道，什麼時候部分或所有訂閱者收到了消息。

這些因素都是要考慮的，會顯著影響到傳輸語義，系統的可靠性，系統效率。

標準和協議

從歷史來看，消息隊列使用了專有的，封閉的協議，以約束不一樣的操做系統或編程語言在異構環境中交互的能力。

讓消息隊列更加普遍認知的早期嘗試是Sun Microsystem的JMS規範，它提供了僅供Java的客戶端API。容許Java開發人員切換消息隊列提供者，相似開發人員使用SQL數據庫的方式。在實踐中，多樣化的消息隊列技術和方案，並不老是像應有的那般實用。

最近，已經出現了三個標準，使得消息隊列開放而普遍：

• 高級消息隊列協議
• MQTT
• 面向流文本的消息傳遞協議

這些全都處於標準化和採納的不一樣階段。他們運轉在HTTP的同一層次。

一些專有實現，也使用HTTP來提供消息隊列，如Amazon的SQS。

這是由於它總能使用請求-響應語義經由同步協議來分層異步行爲（這正是消息隊列須要的）。然而這種狀況下，這種實現受到底層協議限制，並且可能沒法給傳遞的消息提供必須的完整保真度或設置選項。

同步與異步

許多同步操做的通訊協議更加衆所周知。HTTP協議 – 用於萬維網和Web服務 – 提供了一個明顯的例子，用戶發送一個網頁請求，而後等待答覆。

然而，存在這樣的狀況，此時同步的行爲是不恰當的。例如，AJAX（ 異步JavaScript和XML）可用於異步發送文本或XML消息，來用更多的相關信息更新一個網頁的一部分。谷歌在他的谷歌建議（自動填充）中使用了這種途徑，搜索功能將用戶輸入的部分查詢發送到谷歌的服務器，並返回一個列表，包含用戶會錄入的可能的完整查詢。這個列表是在用戶錄入時異步更新的。

其餘異步的例子存在於事件通知系統和發佈/訂閱系統。

• 一個應用程序可能須要通知別人事件發生了，但並不須要等待響應。
• 在發佈/訂閱系統中，應用程序「發佈」信息，任意數量的客戶端閱讀。

在上面的例子中，讓信息發送者等待是不合理的，例如，若是其中一個接收方已崩潰。

應用程序沒必要僅做同步或異步 。交互的應用程序可能須要當即迴應部分請求（如告訴客戶，銷售請求已被接受，正在處理庫存調貨預定），可是也許隊列中的其餘部分（如完成費用計算，將數據轉發到中心記帳系統，還有調用各類其它服務）會過一會才完成。

在這些狀況下，用一個子系統進行消息排隊（或可選擇廣播消息系統）可有助於提升總體系統的行爲。