前言
簡單理解
就是需要大家都遵守的 套規 。在計算機領域中，只要涉及不同的計算機之間要共同完成一
事情的時候，就肯定會有協議的存在，就像我們說話用某種語言一樣，不 同的計算機之間必
須使用相同的語 才能進行通信
消息協議則是指用於實現消息隊列功能時所涉及的協議。按照是否向行業開放消息規范文
檔，可以將消息協議分為開放協議和私有協議。常見的開放協議有 AMQP, MQTT STOMP,XMPP 等。有些特殊框架（如 Red Kafka ZeroMQ ）根據自身需要未嚴格遵循 MQ 規范，而
是基於 TCP IP 自行封裝了 協議，通過網 Socket 接口進行傳輸，實現了 MQ 的功能。這
的協議可以簡 地理解成對雙方通信 個約定，比如傳過來 衍流數據，其中第
節表示什么， 字節表示什么，類似這樣的約定。本章主要介紹常見的幾種開放協議，
並且主要圍繞每種協議約定的數據格式來闡述，包括每種協議中的基本概念， 及約定的互相
通信的消息數據格式等。
AMQP協議
amqp的三個部分
- 基本概念：基本概念是指 AMQP 內部定義的各組件及組件的功能說明
- 功能命令：是指該協議所定義的 系列命令，應用程序可以基於這些命令來實現相應的功能
- 傳輸層協議：是一個網絡級協議，它定義了數據的 傳輸格式，消息隊列的客戶端可以基於這個協議與消息代理和 AMQP 的相模型進行交互通信，該協議的內容包括數據， 吭處理、信道 用、內容編碼、心跳檢測、數據表示和錯誤處理等。
主要概念
- Message （消息）：消息服務器所處理數據的原子單元。消息可以攜帶內容，從格式上看，消息包括 個內容頭、 組屬性和 個內容體這里所說的消息可以對應到許多不同應用程序的實體，比如 個應用程序級消息、 個傳輸文件、 個數據流幀等。消息可以被保存到磁盤上這樣即使發生嚴重的網絡故障、服務器崩潰 可確保投遞。消息可以有優先級，高優先級的消息會在等待同 個消息隊列時在低優先級的消息之前發送，當消息必須被丟棄以確保消息服務器的服務質量時，服務器將會優先丟棄低優先級的消息 。消息服務器不能修改所接收到的井將傳遞給消費者應用程序的消息容體。消息服務器可以在內容頭中添加額外信息，但不能刪除或修改現有信息。
- Publisher （消息生產者）也是 個向交換器發布消息的客戶端應用程序 對於java來說就是發送請求的那一段代碼
- Exchange （交換器）：用來接收消息生產者所發送的消息井將這些消息路由給服務器中的隊列。
- Binding （綁定） 用於消息隊列和交換器之間的關聯。 個綁定就是基於路由鍵將交換器和消息隊列連接起來的路由規則，所以以將交換器理解成 個由綁定構成的路由表
- Virtual Host （虛擬主機）：它是消息隊列以及相關對象的集合，是共享同一個身份驗證和加密環境的獨 服務器域。每個虛擬主本質上都是 mini 版的消息服務器，擁有自己的隊列、交換器、綁定和權限機制。
- Broker （消息代理） 表示消息隊列服務器實體，接受客戶端連接，實現 AMQP 消息隊列和路由功能的過程
- Routing Key （路由規則〉：虛擬機可用它來確定如何路由一個特定消息。
- Queue （消息隊列）：用來保存消息直到發送給消費者。它是消息的容器，也是消息的終點。一個消息可被投入 個或多個隊中息一直在隊列里面，等待消費者連接到這個隊列將其取走。
- Connection （連接〉 可以理解成客戶端和消息隊列服務器之間的 TCP 連接
- Channel （信道）：僅僅當創建了連接后，若客戶端還是不能發送消息，則需要為連接創建一個信道。信道是 條獨立的雙向數流通道，它是建立在真實的 TCP 連接內的虛擬連接， AMQP 令都是通過信道發出去的，不管是發布消息、訂閱隊列還是接收消息，它們都通過信道完成。 個連接可以包含多個信道，之所以需要信道，==是因為TCP 接的建立和釋放都是 分昂貴的，==如果客戶端的每 個線程都需要與消息服務器交互，如果每 個線程都建立了 TCP 連接，暫且不考慮 TCP 接是否？浪費，就算操作系統也無法承受每秒建立如此多的 TCP 連接
核心組件的生命周期
(1 ）消息的生命周期
生產者（ Publisher ）在發布消息時可 給消息指定各種消息屬性（ message meta-data ），其中有些屬性有可能會被消息代理（ Broker ）所使用，而其他屬性則是完全不透明的， 們只能被接收消息的應用所使用。當消息到達服務器時，交換器通常會將消息路由到服務器上的消息隊列中，如果消息不能路由，則交換器會將消息丟棄或者將其返回給生產者，這樣生產者可以選擇如何來處理未路由的消息。單條消息可存在於多個消息隊列中 ，消息代理可以采用 復制消息等多種方式進行處理。但是當 條消息被路由到多個消息隊列中時，它在每個消息隊列中都是一樣 。當消息到達消息隊列時，==消息隊列會 嘗試將消息傳遞給消息消費者。如果傳遞不成功 ，則消息隊列會存儲消息（按生產者要求存在者 內存或磁盤中），並 待消 費者准備好。==如果沒有消費者，則消息隊列通過 AMQP 將消息返回給生產者（ 如果需要的話） 。當消息隊列把消息傳遞給消費者后 ，它 從內部 中刪除消息，刪除動作可能是 發生的， 可能在消費者應答 己成功處理之后再刪除。消息消費者可選擇如何及何時來應答消息，同 消費者也可以拒絕消息 （一個否定應答〉。
(2）交換器的生命周期
每台 AMQP 務器都預先 建了許多交換器實例，它們在服務器啟動時就存在並且不能被銷毀 如果你的應用程序有特殊要求，則可以選擇自己創建交換器，並在完成工作后進行銷毀
（3）隊列的生命周期
這里主要有兩種消 隊列的生命周期，即持久化消息隊列和臨時消息隊列。持久化消息隊列可被 個消費者共享 不管是否有消費者接收，它們都可 以獨立存 臨時消 隊列對消費者是私有的，只能綁定到此消費者，當消費者斷開連接時，該消息隊列將被刪除。
MQTT 協議
它是一個基於TCP IP 協議、可提供發布／訂閱消息模式、十分輕量級的通信協議。除標准版外，還有 個簡化版本MQTT SN ，它基於非 TCP IP 協議（如 ZigBee 協議），該協議主要為嵌入式設備提供消息通信。這里主要介紹標准版 MQTT 3.1.1 ，該協議是一個基於客戶端－服務器的消息發布／訂閱傳輸協議，其特點是輕量、簡單、開放和易於實現。正因為這些特點，使它常應用於很多機器計算能力有限、低帶寬、網絡不可 的遠程通信應用場景中。
目前有很多 MQT 消息中間件服務器，如下都是 MQTT 協議的服務器端的實現
IBM WebSphere MQ Teleme IBM MessageSig Mosquitto clipse ho emqttd Xively
m2m.io webMethods Nirvana Messa ing == RabbitMQ pache ActiveMQ == Apache Apollo
Moque仗隊 HiveMQ Mosca Litmus Automation Loop JoramMQ hingMQ VemeMQ
主要概念
所有基於 網絡連接的應用都會有客戶端（ Client ）和服務器（ Server ），而在 MQTT 協議使用者有 種身份： 發布者（ Publisher ）、代理（ Broker ）和訂閱者（ Subscriber ）。其中消息的發布者和 訂閱者都是客戶端，消息代理是服務器 消息發布者可以同時是訂閱者。
一條消息 流轉過程是這樣的 先由消息發布者發布消息到代理服務器，在消息中會包含
主題（ Topic ），之后消息訂閱者如果訂閱了該主題的消息，將會收到代理服務器推送的消息
MQTT 協議中的 組件
- 網絡連接（ Network Connection )：網絡連接 客戶端連接到服務器時所使 有的底層傳輸協議，由該連接來負責提供有序的、可靠的基於字節流的雙向傳輸
- 應用消息（ ppli cat ion Message )：應用消息指通過網絡所傳輸的應用數據，該數據 般包括 題和負載兩部分。
- 主題（ Topic）：主題題相當於應用消息的類型 ，消息訂閱者訂閱后，就會收到該主題的消 內容
- 負載（ Payload）： 負載指消息訂閱者具體接收的內容
- 客戶端（Client）客戶端指使用 MQTT 程序或設備 客戶端總是通過網絡連接到服務端，它可以發布應用消息給其他相關的客端、訂閱消息用以請求接收相關的應用消息、取消訂閱應用消息、從服務器斷開連接等。
- 服務器（ Server)：服務器也是指程序或設備，它作為發送消息的客戶端束 請求訂閱的客戶端之間的中介。服務器的功能包括接收來自客戶端的網絡連接、接收客戶端發布的應用消息、處理客戶端的訂閱和取消訂閱的請求、轉發應用消息給相應的客戶端等
- 會話（ Sess on)：客戶端與服務器建立連接之后就是 個會話，客戶端和服務器之間通過會話來進行狀態交互。會話存在於一個網絡連接之間，也可能會跨越多個連續的網絡連接。會話主要用於客戶端和服務器之間的邏輯層面的通信
- 訂閱（ Su scripti on)：訂閱一般與 個會話關聯，會話可以包含多於 個的訂閱。訂閱包含 個主題過濾器和個服務質量（ QoS ）等級。會話的每個訂閱都有 個不同的主題過濾器。
- 主題名（ opic Name)：主題名是附加在消息上的一個標簽，該標簽與服務器的訂閱相匹配，服務器會根據該標簽將消息發送給與訂閱所匹配的每個客戶端
- 主題過濾器（ pi Filter)：主題過濾器是訂閱中包含的一個表達式，用於表示相關聯的一個或多個主題。主題過濾器可以使用通配衍。
- MQTT 控制拇文 CMQT Control Packet)：MQT 控制報文實際上就是通過網絡連接發送的信息數據包。
STOMP 協議
STOMP ( Streaming Text Orientated Messaging Protocol 流文本定向消息協議〉是 個簡單
的文本消息傳輸協議， 它提供了 種可互操作的連接格式，允許客戶端與任意消息服務器
Broker ）進行交互 如下都 STOMP
協議的服務器端實現。
Apache Apollo Apach ActiveMQ RabbitMQ Horn tQ Sta mpy StompServer
主要概念
與其他消 協議相 同， STOMP 同樣包含客戶端和服務器，這里的客戶端既可以是消息生產者，也可以是消息梢費者，而服務器就是消息數據的目的地，所有消息都會被發送到服務器
STOMP 客戶端和服務器之間的通信是基於 來實現的 每一 都包括一 表示命令
符串、一系列可選的 頭條目和幀的數據內容。幀的數據格式如下
JMS 協議
JMS CJava Message Service) ep Java 消息服務應用程序接口，是 Ja 平台中面向消息中間
件的 套規范的 JavaAP 接口，用於在兩個應用程序之間或分布式系統中發送消息，進行異步
通信 這套規范由 IB 提出
jms並不是消息隊列協議的 種，更不是消息隊列產品，它是與具體平台無關 API 目前市
面上的絕大多數消息中間件廠商都支持 接口規范 換句話說 你可 使用 JMSAPI 來連接
支持 AMQP STOMP 等協議的消息中間件產品（比如 Act veM RabbitMQ 等），在這一點上
它與 Java 中的 IDB 的作用很像，我們可以用 IDB CAPI 來訪問具體的數據庫產品（ Oracle
My 等）。
體系架構
JMS 之前，大部分消息隊列產品都支持點對點 發布 訂閱兩種方式來傳遞消息。基於
此， JMS 將這兩種消息模型抽象成兩類規范，它們相互獨立，由 JMS 的提供商（即消息隊列產
品的具體廠商〉自己選擇實現其中的 種還是兩 模型。 JMS 的作用是提供通用接口保證基於
JMS PI 編寫 程序適用於任何 種模型 使得在更換消息隊列提供商 況下 程序
代碼也不需要做太大 改動。
(1 ） 點對點模型在點對點（ Point to int ）模型中，應用程序由隊列（ Queue ）、發送者（ Sender ）和接
(Receiver ）組成。每條消息都被發送到一個特定的隊列中，接收者從隊列中獲取消息（ ）。
隊列中 直保留着消息，直到它們被接收或超時。點對點模型的特點如下：
- 每條消息只有一個接收者，消息一旦被接收就不再保留在消息隊列中了。
- 發送者 接收者之間在時間上沒有依賴。也就是說，當消息被發送之后 不管接收者有沒有在運行，都不會影響消息被發送到隊列中。
- 每條消息僅會被傳送給 個接收者 也就是說， 個隊列中可能會有多個接收者聽，但是消息只能被隊列中的 個接收者接收
- 消息存在先后順序 。一個隊列會按照消息服務器將消息放入隊列中的順序把它們傳送給接收者。當消息己經被接收時就會從隊列頭部將它們刪除（除非使用了消息優先級）
- 當接收者收 消息時，會發送確認收到通知
所以，一般情況下，如果希望所發送的每條消息都能被成功處理，則需要使用點對點模型
(2 ）發布／訂閱模型
在發布／訂閱（ Pub Sub ）模型中，應用程序由主題（ Topic ）、發布者（ Publi ）和訂閱者
Subsc ）組成。發布者發布 條消息，該消息通過 題傳遞給所有的訂閱者
在這種模型中，發布者和訂閱者彼此不知道對方，它們是匿名的井且可以動態發布和訂閱主題。
主題用於保存和傳遞消息，並且會 直保存消息直到消息被傳遞給訂閱者。
發布／訂閱模型的特點如下：
- 每條消息可以有多個訂閱者
- 發布者和訂閱者之間有時間上的依賴 一般情況下，某個主題的訂閱者需要在創建了訂閱之后才能接收到消息，而且為了接收消息訂閱者必須保持運行的狀態。
- JMS 允許訂閱者創建 可持久化的訂閱，這樣即使訂閱者沒有運行也能接收到所閱的消息
- 每條消息都會傳送給該主題下的所有 訂閱者
- 通常發布者不會知道 意識不到哪一個訂閱者正在接收消息所以，如果希望所發送的消息不被做任何處理或者被 個或多個訂閱者 ，則可以使用發布／訂閱模型。
基本概念
按照、JMS 規范中所說的， 一個JMS 應用由如下幾個部分組成。
- JMS 客戶端（ JMS Client): 指發送和接收消息的 Java 程序
- 非JMS 客戶端（Non JMS Client ）：指使用消息系統原生 客戶端 API 代替 JMS 的客戶端。 果應用程序在 JMS 規范前就己存在， 它可能同時包 JMS 客戶端 JMS客戶端。
- 消息（ Message） 每個應用都定義了一組消息，用於多 客戶端之間的消息通信
- JMS 提供商（ JMS Provider ）：指實現了 JMS API 實際消息系統。
- 受管對象（ Administered Obect ：指由 管理員創建， 並預先 好給客戶端使用的血但對象。 JMS 中的受管對象分為兩種，即 ConnectionFactory （客戶端使用這個對象來建到提供者的連接）和 Destination （客戶端使用這個對象來指定發送或接收消息的目
的地）。
具體到 JMS 應用程序， 主要涉及以 基本概念
- 生產者（ Producer 建並發送消息 JMS 客戶端，在點對點模型中就是發送者 ，在發布/訂閱模型中就是發布者
- 消費者（ Consumer ）： 接收消息的 JMS 客戶端 在點對點模型中就是接收者 在發訂閱模型中就是訂閱者。
- 客戶端（ lient ）：生產或消費消息的基於 Jav 應用程序或對象。
- 隊列（ Queue 個容納被發送的等待閱讀的消息的區域。它是點對點模型中的隊列。
- 主題（ Topic ）：一種支持發送消息給多個訂閱者的機制。它是發布／訂閱模型中的主題。
- 在 JMS 客戶端之間傳遞的數據對象。 JMS 消息又包括消息頭、屬性和消息體 部分。消息頭是指所有消息都支持的相同的頭字段集，它包含了客戶端JMS 提供商都要使用的用於標識和路由消息的值 屬性是指除標准的頭宇段外，消息接口還 含了 支持屬性值的內建機制 實際上，這 是為消息提供了 加可選的消息頭字段的機制。消息屬性包括應用專有屬性、標准屬性、提供商專有屬性
JMS 定義了幾種消息體類型，這些類型覆蓋了當前使用的大部分消息風格。消息體就是指實際的消息內容。
編程接口
ConnectionFactory 接口（連接工廠〉
ConnectionFactory onnection 工廠，根據不同的消息類型用戶可選擇用隊列
連接工廠或者主題連接 廠，分別對應 QueueConnecti onF actory TopicConnectionFactory
以通過 JNDI 來查找 ConnectionFactory 對象。
Destination 接口（目的地）
Destination 是一 包裝了消息目的地標識符的受管對象 消息目的地是指消息發布和接收的地點，消息目的地要么是隊列要么是主題。對於消息生產者來說 ，它的 Destination 是某個隊列或某個主題：對於消息消費者來說，它的 Destination 是某個隊列或主題（ 即消息來源）。所以 Destination 實際上就是兩種類型的對象 Queue Topic 可以通過 JNDI 來查找 Destination
Connection 接口（連接）
Connection 表示在客戶端和 JMS 系統之 建立的連接（實際上是對 TCP IP Socket 的包裝）。
Connection 可以產生 個或多個 Session ，跟 ConnectionFactory 樣， onnection 有兩 類型
QueueConnection TopicConnection
Session 接口（會話）
Session 是實際操作消息的接口，表示一 單線程的上下文，用於發送和接 消息。因為會
話是單線程的，所以消息是按照發送的順序 個個接收的 。可 以通過 Session 創建生產者、消費
者、消息等。在規范 Session 還提供了事務的功能。 Session 分為兩種類型 QueueSession
軍日 TopicSession
MessageProducer 接口（消息生產者〉
消息生產者由 Session 創建並用於將消息發送到 Destination 消費者可以 步（阻塞模式）
或異步（非阻塞模式）接收隊列和主題類型的消息。消息生產者有兩種類型 QueueSender
TopicPublisher
MessageConsumer 接口（消息消費者）
消息消費者由 Session 建，用於接收被發送到 Destination 的消息。消息、消費者有兩種類刑
QueueReceiver TopicSubscriber
Message 接口（消息〉
消息是在 費者 生產者之 傳送 對象，即將消 應用程序發送 應用程序。
MessageListener （消息監 器）
如果果注冊 消息監聽 那么當消息 將自動調用監 onMessage 方法。
總結
在使用消息隊列時肯定需要了JMS ，該規范實際上是對 AMQPMQTT STOMP XMPP 等消息通信協議的更高 層的抽象 從消息隊列使用者的角度來看，JMS 對所需要 理的常規 題都已經提供了相關支持
節選自-------《分布式消息中間件實踐》 可以在腳本之家下載