消息隊列簡介

 

 

1、概述

計算機科學中，消息隊列和郵箱是用於進程間或者線程與同一進行間通信的軟件工程組件。他們都是消息傳傳輸控制隊列。

消息隊列是發佈/訂閱模型的變種，是較大的面向消息的中間件的一部分。多數消息系統支持發佈/訂閱和消息隊列模型的API，如JMS（Java Message Service）。

消息隊列提供異步的通信協議，這就意味着消息發送者和消息接收者不須要在同一時間與消息隊列交互。消息入隊直到接收者來讀取。消息隊列都有單條消息大小的限制，入隊消息的數目也有限制。

消息隊列的主要應用是在不一樣計算機系統間進行通信，能夠鏈接多個應用和多種操做系統。有時消息隊列增長了一種加強功能，確認在系統失效時不丟失消息。

多數實時操做系統，如VxWorks和QNX，鼓勵使用消息隊列做進行間或者線程間主要的通信機制。Erlang語言使用進程，提供一樣的功能。這些進程使用消息隊列進行異步通信。

2、用例

在一個典型的消息隊列應用場景中，系統管理員安裝和配置消息隊列軟件，並命名消息隊列或者註冊消息服務。應用程序的進程註冊並監聽消息。接下的應用鏈接到隊列，並在此之上傳送消息。

消息隊列管理軟件保存消息直到接收程序鏈接到隊列。接收程序接收並處理消息。

有多種消息處理模塊：

一、持久存儲。消息保存在內容，並寫到磁盤中，甚至寫入數據庫；

二、安全策略。控制哪一個程序才能訪問隊列；

三、消息存活策略。隊列和消息存在一個有效期；

四、消息過濾。支持消息路由，只接收選擇的數據；

五、送達策略。至少一次或者其餘；

六、路由策略。在多服務系統，那個服務應該接收到消息；

七、批處理策略。消息是當即投遞或者稍等一會一塊投遞；

八、入隊條件。何時才能稱已經入隊；

九、接收通知。消息發佈者可能須要消息訂閱是否已經接收到消息。

3、標準和協議

歷史上，消息隊列曾用私有的、封閉的協議，這就限制了不一樣操做系統或者不一樣編程語言在一個異構的環境中進行通信。

早期通用化嘗試爲SUN公司的JMS，他只提供Java語言API的客戶端。這就給Java開發人員提供了一種類型數據庫開發人員使用的SQL語言。在實際應用中，考慮到消息隊列的差別及應用場景的不一樣，很難作到通用。

在開源消息隊列的實現過程當中，逐漸造成了3種標準：

一、AMQP富特徵消息隊列；

二、STOMP，簡單的面向文件的消息隊列；

三、MQTT，輕量級的消息隊列。

這些協議標準程序和接收程序不一樣。AMQP和STOMP和HTTP位於同一層。MQTT與TCP處於同一層。

一些私有化實現，也採用HTTP來提供消息隊列，如Amazon的SQS。由於總存在一種使用基於請求應答機制實現經過異步協議增長異步功能的可能性。

4、同步VS異步

多數普遍使用的通信協議，操做是同步，如應用於萬維網和Web服務中的HTTP協議。HTTP的典型場景是：客戶端發送一個請求，接着等待迴應。

可是與存在一些場景同步操做並不適合。例如AJAX（Asynchronos JavaScript ans XML）用於異步傳送文件、JSON和XML消息，以此來更新部分網頁。Google用AJAX技術實現了Google Suggest，用於傳送部分已經匹配客戶查詢信息列表，這個列表異步更新。

其餘異步用例存在於事件通知系統和發部/訂閱系統中：

一、一個應用可能須要通信其餘應用一個事件的發生，但不須要等待迴應；

二、在發部/訂閱系統中，一個應用發部信息給多個客戶端去讀。

上述兩個例都沒有必要等待響應，就算一個接收宕掉。

應用不須要只異步或者同步。一個應用能夠部分功能使用異步方式，部分功能使用同步方式。