消息是JMS中的一種類型對(duì)象，由兩部分組成：消息頭和消息體（或分三部分：消息頭、屬性、消息體）。消息頭由路由信息以及有關(guān)該消息的元數(shù)據(jù)組成。消息體則攜帶著應(yīng)用程序的數(shù)據(jù)或有效負(fù)載。
JMSDeliveryMode：傳遞模式，有兩種模式： PERSISTENT和NON_PERSISTENT，PERSISTENT表示該消息一定要被送到目的地，否則會(huì)導(dǎo)致應(yīng)用錯(cuò)誤。NON_PERSISTENT表示偶然丟失該消息是被允許的，這兩種模式使開(kāi)發(fā)者可以在消息傳遞的可靠性和吞吐量之間找到平衡點(diǎn)。標(biāo)記為NON_PERSISTENT的消息最多投遞一次，而標(biāo)記為PERSISTENT的消息將使用暫存后再轉(zhuǎn)送的機(jī)理投遞。如果一個(gè)JMS服務(wù)離線，那么持久性消息不會(huì)丟失但是得等到這個(gè)服務(wù)恢復(fù)聯(lián)機(jī)時(shí)才會(huì)被傳遞。所以默認(rèn)的消息傳遞方式是非持久性的。
JMSExpiration：消息過(guò)期時(shí)間，等于QueueSender的send方法中的timeToLive值或TopicPublisher的publish方法中的timeToLive值加上發(fā)送時(shí)刻的GMT時(shí)間值。如果timeToLive值等于零，則JMSExpiration被設(shè)為零，表示該消息永不過(guò)期。如果發(fā)送后，在消息過(guò)期時(shí)間之后消息還沒(méi)有被發(fā)送到目的地，則該消息被清除。
JMSPriority：消息優(yōu)先級(jí)，從0-9 十個(gè)級(jí)別，0-4是普通消息，5-9是加急消息。JMS不要求JMS Provider嚴(yán)格按照這十個(gè)優(yōu)先級(jí)發(fā)送消息，但必須保證加急消息要先于普通消息到達(dá)。
JMSRedelivered：如果一個(gè)客戶端收到一個(gè)設(shè)置了JMSRedelivered屬性的消息，則表示可能該客戶端曾經(jīng)在早些時(shí)候收到過(guò)該消息，但并沒(méi)有簽收(acknowledged)。
除了消息頭中定義好的標(biāo)準(zhǔn)屬性外，JMS提供一種機(jī)制增加新屬性到消息頭中，這種新屬性包含以下幾種：應(yīng)用需要用到的屬性、消息頭中原有的一些可選屬性、JMS Provider需要用到的屬性。
2）消息體：JMS API定義了5種消息體格式，也叫消息類型，你可以使用不同形式發(fā)送接收數(shù)據(jù)并可以兼容現(xiàn)有的消息格式，下面描述這5種類型：
TextMessage：java.lang.String對(duì)象，如xml文件內(nèi)容
MapMessage：名/值對(duì)的集合，名是String對(duì)象，值類型可以是Java任何基本類型
BytesMessage：字節(jié)流
StreamMessage：Java中的輸入輸出流
ObjectMessage：Java中的可序列化對(duì)象
Message：沒(méi)有消息體，只有消息頭和屬性
3）消息可靠性
在上面談及消息體格式定義中，有個(gè)字段JMSDeliveryMode用來(lái)表示該消息發(fā)送后，JMS提供商應(yīng)該怎么處理消息。PERSISTENT（持久化）的消息在JMS服務(wù)器中持久化。接收端如果采用點(diǎn)對(duì)點(diǎn)的queue方式或者Durable Subscription（持久訂閱者）方式，那么消息可保證只且只有一次被成功接收。NON_PERSISTENT(非持久化)的消息在JMS服務(wù)器關(guān)閉或宕機(jī)時(shí)，消息丟失。根據(jù)發(fā)送端和接收端采用的方式，列出如下可靠性表格，以作參考。
注意：以下的可靠性不包括JMS服務(wù)器由于資源關(guān)系，造成的消息不能持久化等因素引起的不可靠（該類不可靠應(yīng)該是JMS提供商或硬件引起的的資源和處理能力的極限問(wèn)題，應(yīng)該由管理人員解決）。也不包括消息由于超時(shí)時(shí)間造成的銷毀丟失。
消息發(fā)送端 消息接收端 可靠性及因素
PERSISTENT queue receiver/durable subscriber 消費(fèi)一次且僅消費(fèi)一次。可靠性最好，但是占用服務(wù)器資源比較多。
PERSISTENT non-durable subscriber 最多消費(fèi)一次。這是由于non-durable subscriber決定的，如果消費(fèi)端宕機(jī)或其他問(wèn)題導(dǎo)致與JMS服務(wù)器斷開(kāi)連接，等下次再聯(lián)上JMS服務(wù)器時(shí)消息不保留。
NON_PERSISTENT queue receiver/durable subscriber 最多消費(fèi)一次。這是由于服務(wù)器的宕機(jī)會(huì)造成消息丟失
NON_PERSISTENT non-durable subscriber 最多消費(fèi)一次。這是由于服務(wù)器的宕機(jī)造成消息丟失，也可能是由于non-durable subscriber的性質(zhì)所決定
4）消息的優(yōu)先級(jí)
雖然JMS規(guī)范并不需要JMS供應(yīng)商實(shí)現(xiàn)消息的優(yōu)先級(jí)路線，但是它需要遞送加快的消息優(yōu)先于普通級(jí)別的消息。JMS定義了從0到9的優(yōu)先級(jí)路線級(jí)別，0是最低的優(yōu)先級(jí)而9則是最高的。更特殊的是0到4是正常優(yōu)先級(jí)的變化幅度，而5到9是加快的優(yōu)先級(jí)的變化幅度。舉例來(lái)說(shuō)：
topicPublisher.publish (message, DeliveryMode.PERSISTENT, 8, 10000); //Pub-Sub
或 queueSender.send(message,DeliveryMode.PERSISTENT, 8, 10000);//P2P
這個(gè)代碼片斷，有兩種消息模型，映射遞送方式是持久的，優(yōu)先級(jí)為加快型，生存周期是10000 (以毫秒度量)。如果生存周期設(shè)置為零，這則消息將永遠(yuǎn)不會(huì)過(guò)期。當(dāng)消息需要時(shí)間限制否則將使其無(wú)效時(shí)，設(shè)置生存周期是有用的。
5）消息的通知確認(rèn)
在客戶端接收了消息之后，JMS服務(wù)怎樣有效確認(rèn)消息是否已經(jīng)被客戶端接收呢？
Session session=connection.createSession(false,Session.AUTO_ACKNOWLEDGE);
這段代碼創(chuàng)建一個(gè)非事務(wù)性的session，并采用auto_acknowledge方式通知JMS服務(wù)器。如果采用事務(wù)性session時(shí)，通知會(huì)伴隨session的commit/rollback同時(shí)發(fā)送通知。在我們采用非事務(wù)session時(shí)，有三種通知方式。
通知方式 效果
DUPS_OK_ACKNOWLEDGE session 延遲通知。如果JMS服務(wù)器宕機(jī)，會(huì)造成重復(fù)消息的情況。程序必須保證處理重復(fù)消息而不引起程序邏輯的混亂。
AUTO_ACKNOWLEDGE 當(dāng)receive或MessageListener方法成功返回后自動(dòng)通知。
CLIENT_ACKNOWLEDGE 客戶端調(diào)用消息的acknowledge方法通知
5、PTP模型
點(diǎn)對(duì)點(diǎn)（Point- to-Point）消息傳送使用的目標(biāo)是隊(duì)列。通過(guò)使用隊(duì)列，消息可以被異步或同步地發(fā)送和接收。每一條到達(dá)隊(duì)列的消息將會(huì)被投遞到單獨(dú)一個(gè)消費(fèi)者一次，并且只有一次。這就好像兩個(gè)人之間的郵件發(fā)送。消費(fèi)者可以通過(guò)MessageConsumer.receive（）方法同步地接收消息或使用 MessageConsumer.setMessageListener()方法注冊(cè)一個(gè)MessageListener實(shí)現(xiàn)來(lái)異步地接收消息。隊(duì)列保存所有的消息直到它們被投遞出去或過(guò)期。
JMS PTP模型中的主要概念和對(duì)象：
Queue：由JMS Provider管理，隊(duì)列由隊(duì)列名識(shí)別，客戶端可以通過(guò)JNDI接口用隊(duì)列名得到一個(gè)隊(duì)列對(duì)象。
TemporaryQueue：由QueueConnection創(chuàng)建，而且只能由創(chuàng)建它的QueueConnection使用。
QueueConnectionFactory：客戶端用QueueConnectionFactory創(chuàng)建QueueConnection對(duì)象。
QueueConnection：一個(gè)到JMS PTP provider的連接，客戶端可以用QueueConnection創(chuàng)建QueueSession來(lái)發(fā)送和接收消息。
QueueSession：提供一些方法創(chuàng)建QueueReceiver 、QueueSender、QueueBrowser和TemporaryQueue。如果在QueueSession關(guān)閉時(shí)，有一些消息已經(jīng)被收到，但還沒(méi)有被簽收(acknowledged)，那么，當(dāng)接收者下次連接到相同的隊(duì)列時(shí)，這些消息還會(huì)被再次接收。
QueueReceiver：客戶端用QueueReceiver接收隊(duì)列中的消息，如果用戶在QueueReceiver中設(shè)定了消息選擇條件，那么不符合條件的消息會(huì)留在隊(duì)列中，不會(huì)被接收到。
QueueSender：客戶端用QueueSender發(fā)送消息到隊(duì)列。
QueueBrowser：客戶端可以QueueBrowser瀏覽隊(duì)列中的消息，但不會(huì)收走消息。
QueueRequestor：JMS提供QueueRequestor類簡(jiǎn)化消息的收發(fā)過(guò)程。QueueRequestor的構(gòu)造函數(shù)有兩個(gè)參數(shù)：QueueSession和queue，QueueRequestor通過(guò)創(chuàng)建一個(gè)臨時(shí)隊(duì)列來(lái)完成最終的收發(fā)消息請(qǐng)求。
可靠性(Reliability)：隊(duì)列可以長(zhǎng)久地保存消息直到接收者收到消息。接收者不需要因?yàn)閾?dān)心消息會(huì)丟失而時(shí)刻和隊(duì)列保持激活的連接狀態(tài)，充分體現(xiàn)了異步傳輸模式的優(yōu)勢(shì)。
可以看到，一個(gè)或多個(gè)生產(chǎn)者發(fā)送消息，消息m2先抵達(dá)了queue，然后m1也發(fā)出了，并一同存在于一個(gè)先進(jìn)先出的queue里面。消費(fèi)者也存在一個(gè)或多個(gè)，對(duì)queue里的消息進(jìn)行消費(fèi)。但一個(gè)消息只會(huì)被的一個(gè)消費(fèi)者消費(fèi)且僅消費(fèi)一次。
6、PUB/SUB模型
JMS Pub/Sub模型定義了如何向一個(gè)內(nèi)容節(jié)點(diǎn)發(fā)布和訂閱消息，這些節(jié)點(diǎn)被稱作主題(topic)。主題可以被認(rèn)為是消息的傳輸中介，發(fā)布者(publisher)發(fā)布消息到主題，訂閱者(subscribe)從主題訂閱消息。主題使得消息訂閱者和消息發(fā)布者保持互相獨(dú)立，不需要接觸即可保證消息的傳送。
JMS Pub/Sub 模型中的主要概念和對(duì)象：
訂閱（subscription）：消息訂閱分為非持久訂閱(non-durable subscription)和持久訂閱(durable subscrip-tion)，非持久訂閱只有當(dāng)客戶端處于激活狀態(tài)，也就是和JMS Provider保持連接狀態(tài)才能收到發(fā)送到某個(gè)主題的消息，而當(dāng)客戶端處于離線狀態(tài)，這個(gè)時(shí)間段發(fā)到主題的消息將會(huì)丟失，永遠(yuǎn)不會(huì)收到。持久訂閱時(shí)，客戶端向JMS注冊(cè)一個(gè)識(shí)別自己身份的ID，當(dāng)這個(gè)客戶端處于離線時(shí)，JMS Provider會(huì)為這個(gè)ID保存所有發(fā)送到主題的消息，當(dāng)客戶再次連接到JMS Provider時(shí)，會(huì)根據(jù)自己的ID得到所有當(dāng)自己處于離線時(shí)發(fā)送到主題的消息。
Topic：主題由JMS Provider管理，主題由主題名識(shí)別，客戶端可以通過(guò)JNDI接口用主題名得到一個(gè)主題對(duì)象。JMS沒(méi)有給出主題的組織和層次結(jié)構(gòu)的定義，由JMS Provider自己定義。
TemporaryTopic：臨時(shí)主題由TopicConnection創(chuàng)建，而且只能由創(chuàng)建它的TopicConnection使用。臨時(shí)主題不能提供持久訂閱功能。
TopicConnectionFactory：客戶端用TopicConnectionFactory創(chuàng)建TopicConnection對(duì)象。
TopicConnection：TopicConnection是一個(gè)到JMS Pub/Sub provider的連接，客戶端可以用TopicConnection創(chuàng)建TopicSession來(lái)發(fā)布和訂閱消息。
TopicSession：TopicSession提供一些方法創(chuàng)建TopicPublisher、TopicSubscriber、TemporaryTopic 。它還提供unsubscribe方法取消消息的持久訂閱。
TopicPublisher：客戶端用TopicPublisher發(fā)布消息到主題。
TopicSubscriber：客戶端用TopicSubscriber接收發(fā)布到主題上的消息。可以在TopicSubscriber中設(shè)置消息過(guò)濾功能，這樣，不符合要求的消息不會(huì)被接收。
Durable TopicSubscriber：如果一個(gè)客戶端需要持久訂閱消息，可以使用Durable TopicSubscriber，TopSession提供一個(gè)方法createDurableSubscriber創(chuàng)建Durable TopicSubscriber對(duì)象。
恢復(fù)和重新派送(Recovery and Redelivery)：非持久訂閱狀態(tài)下，不能恢復(fù)或重新派送一個(gè)未簽收的消息。只有持久訂閱才能恢復(fù)或重新派送一個(gè)未簽收的消息。
TopicRequestor：JMS提供TopicRequestor類簡(jiǎn)化消息的收發(fā)過(guò)程。TopicRequestor的構(gòu)造函數(shù)有兩個(gè)參數(shù)：TopicSession和topic。TopicRequestor通過(guò)創(chuàng)建一個(gè)臨時(shí)主題來(lái)完成最終的發(fā)布和接收消息請(qǐng)求。
可靠性(Reliability)：當(dāng)所有的消息必須被接收，則用持久訂閱模式。當(dāng)丟失消息能夠被容忍，則用非持久訂閱模式。
在pub/sub消息模型中，消息被廣播給所有訂閱者。訂閱者可以同步接收消息也可以異步接收消息，消息的同步接收是指客戶端主動(dòng)去接收消息，消息的異步接收是指當(dāng)消息到達(dá)時(shí)，主動(dòng)通知客戶端。
使用JMeter測(cè)試JMS
JMeter是Apache開(kāi)發(fā)的一款小巧易用的開(kāi)源性能測(cè)試工具，由java語(yǔ)言開(kāi)發(fā)。JMeter不僅免費(fèi)開(kāi)源而且功能強(qiáng)大、易于擴(kuò)展，如果有一定Java開(kāi)發(fā)基礎(chǔ)的話還可以在JMeter上做擴(kuò)展開(kāi)發(fā)新的插件等，幾乎能滿足各種性能測(cè)試需求。JMeter中使用Sampler元件（取樣器）來(lái)模擬各種的類型的請(qǐng)求數(shù)據(jù)格式，類似于LR中的協(xié)議（比LR中的協(xié)議概念更廣），如：http、ftp、soap、tcp等等。JMeter中支持的JMS Point-to Point、JMS Publisher和JMS Subscriber分別用于發(fā)送JMS的PTP消息和PUB/SUB消息，因此可以選擇使用JMeter來(lái)測(cè)試JMS。
MOM（消息中間件）作為消息數(shù)據(jù)交換的平臺(tái)，也是影響應(yīng)用執(zhí)行效率的潛在環(huán)節(jié)。在Java程序中，是通過(guò)JMS與MOM進(jìn)行交互的。作為Java實(shí)現(xiàn)的性能測(cè)試工具JMeter也能使用JMS對(duì)應(yīng)用的消息交換和相關(guān)的數(shù)據(jù)處理能力進(jìn)行測(cè)試。在整個(gè)測(cè)試過(guò)程中，JMeter測(cè)試的重點(diǎn)是消息的產(chǎn)生者和消費(fèi)者的能力，而不是MOM本身。JMeter雖然能使用JMS對(duì)MOM進(jìn)行測(cè)試，但是它本身并沒(méi)有提供JMS需要使用的包（實(shí)現(xiàn)類）。因此在使用JMeter測(cè)試JMS時(shí)需要使用到具體的MOM的相關(guān)jar包。以下結(jié)合流行的開(kāi)源消息中間件ActiveMQ來(lái)演示如何使用JMeter來(lái)實(shí)現(xiàn)對(duì)JMS的測(cè)試。
1、安裝并啟動(dòng)ActiveMQ服務(wù)
2、測(cè)試前的準(zhǔn)備
使用JMeter進(jìn)行壓力測(cè)試時(shí)，所有的JMeter依賴的包需要復(fù)制到%JMETER_HOME%/lib目錄下。對(duì)于ActiveMQ來(lái)說(shuō)，就是復(fù)制%ACTIVEMQ_HOME%/lib目錄下jar包，可根據(jù)實(shí)際情況來(lái)考慮是否復(fù)制。JMeter在測(cè)試時(shí)使用了JNDI，為了提供JNDI提供者的信息，需要提供jndi.properties。同時(shí)需要將jndi.properties放到JMeter的%JMETER_HOME%/lib和%JMETER_HOME%/bin目錄中，還需要將jndi.properties與%JMETER_HOME%/bin目錄下的ApacheJMeter.jar打包在一起。對(duì)于ActiveMQ，jndi.properties的演示內(nèi)容如下：
1 #java.naming.factory.initial = org.activemq.jndi.ActiveMQInitialContextFactory 2 java.naming.factory.initial = org.apache.activemq.jndi.ActiveMQInitialContextFactory 3 java.naming.provider.url = tcp://localhost:61616 4 5 #指定connectionFactory的jndi名字，多個(gè)名字之間可以逗號(hào)分隔。 6 #以下為例： 7 #對(duì)于topic，使用(TopicConnectionFactory)context.lookup("connectionFactry") 8 #對(duì)于queue，(QueueConnectionFactory)context.lookup("connectionFactory") 9 connectionFactoryNames = connectionFactory 10 11 #注冊(cè)queue，格式： 12 #queue.[jndiName] = [physicalName] 13 #使用時(shí)：(Queue)context.lookup("jndiName")，此處是MyQueue 14 queue.MyQueue = example.MyQueue 15 16 #注冊(cè)topic，格式： 17 # topic.[jndiName] = [physicalName] 18 #使用時(shí)：(Topic)context.lookup("jndiName")，此處是MyTopic 19 topic.MyTopic = example.MyTopic |
3、測(cè)試JMS的PTP模型
對(duì)于點(diǎn)對(duì)點(diǎn)模型，JMeter只提供了一種Sampler：JMS Point-to-Point。如圖所示建立測(cè)試計(jì)劃：
QueueConnection Factory：連接工廠，輸入jndi配置文件中配置的connectionFactory
JNDI name Request queue：請(qǐng)求隊(duì)列名，輸入jndi配置文件中配置的MyQueue
JNDI name Receive queue：接收隊(duì)列名，輸入jndi配置文件中配置的MyQueue
Content：消息內(nèi)容，比如輸入：this is a test
Initial Context Factory：輸入org.apache.activemq.jndi.ActiveMQInitialContextFactory
Provider URL：提供者URL，即安裝的ActiveMQ的服務(wù)地址tcp://yourIP:61616
運(yùn)行調(diào)試時(shí)通過(guò)監(jiān)視器元件查看是否發(fā)送成功，如下說(shuō)明發(fā)送成功：