1、JMS 簡介｜ 8月更文挑戰

學習activemq前，先了解了解jms

1. 簡介

JMS即Java消息服務（Java Message Service）應用程序接口，是一個Java平臺中關於面向消息中間件（MOM）的API，用於在兩個應用程序之間，或分佈式系統中發送消息（發送消息的時候，接收者不須要在線），進行異步通訊。Java消息服務是一個與具體平臺無關的API，絕大多數MOM提供商都對JMS提供支持。

JMS消息由三部分組成：

消息頭

JMS消息頭預約義了若干字段用於客戶端與JMS提供者之間識別和發送消息，預編譯頭以下：

– JMSDestination ： 消息發送的目的地，主要是指Queue和Topic，由session建立而由生產者的send方法設置.

– JMSDeliveryMode：傳送模式:有兩種即久模式和非持久模式。一條持久性的消息應該被傳輸"一次僅僅一次"，這就意味着若是JMS提供者出現故障，該消息並不會丟失，它會在服務器恢復以後再次傳遞。一條非持久的消息最多會傳遞一次，這意味着服務器出現故障，該消息將永遠丟失。由session穿件由消息生產者的send方法設置

– JMSMessageID：惟一識別每一個消息的標識，由JMS消息生產者產生。由send方法設置

– JMSTimestamp：一個JMS Provider在調用send()方法時自動設置，它是消息被髮送和消費者實際接收的時間差。由客戶端設置

– JMSCorrelationID：用來鏈接到另一個消息，典型的應用是在回覆消息中鏈接到原消息。在大多數狀況下，JMSCorrelationID用於將一條消息標記爲對JMSMessageID標示的上一條消息的應答，不過，JMSCorrelationID能夠是任何值，不單單是JMSMessageID。由客戶端設置

– JMSReplyTo：提供本消息回覆消息的目的地址,由客戶端設置

– JMSRedelivered：若是一個客戶端收到一個設置了JMSRedelivered屬性的消息，則表示可能客戶端曾經在早些時候收到過該消息，但並無簽收(acknowledged)。若是該消息被從新傳送，JMSRedelivered=true 不然 JMSRedelivered=flase 。由JMS Provider設置

– JMSType：消息類型的標識符，由客戶端設置

– JMSExpiration：消息過時時間，等於Destination的send方法中的timeToLive值加上發送時刻的GMT的時間值。若是timeToLive值等於零，則JMSExpiration被設置爲零，表示該消息永不過時。若是發送後，在消息過時時間以後消息尚未被髮送到目的地，則該消息被清除。由send方法設置

– JMSPriority：消息優先級，從0-9十個級別，0-4是普通消息，5-9是加急消息。JMS不要求JMS Provider嚴格按照這十個優先級發送消息，但必須保證加急消息要先於普通消息到達，默認是4級。由send方法設置
`
一個消息的消息頭有這些屬性，咱們能夠按照須要對這個消息的消息進行設計，在將這個消息使用消息生產者的send（）方法發送到消息服務上。

**消息屬性**

咱們能夠給消息設置自定義屬性，這些屬性主要是提供給應用程序的。對於實現消息過濾功能，消息屬性很是有用，JMS API定義了一些標準屬性，JMS服務提供者能夠選擇性的提供部分標準屬性。

**消息體**

在消息體中，JMS API定義了五種類型的消息格式，讓咱們能夠以不一樣的形式發送和接受消息，並提供了對已有消息格式的兼容。不一樣的消息類型以下：
```js
Text message : javax.jms.TextMessage，表示一個文本對象。

Object message : javax.jms.ObjectMessage，表示一個JAVA對象。

Bytes message : javax.jms.BytesMessage，表示字節數據。

Stream message :javax.jms.StreamMessage，表示java原始值數據流。

Map message : javax.jms.MapMessage，表示鍵值對。

複製代碼

2. JMS支持兩種消息發送和接收模型。

1. P2P（Point to Point）點對點模式

P2P模式包含三個角色：消息隊列（Queue），發送者(Sender)，接收者(Receiver)。

每一個消息都被髮送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留着消息，直到他們被消費或超時。

​

P2P的特色：

每一個消息只有一個消費者（Consumer）(即一旦被消費，消息就再也不在消息隊列中)

發送者和接收者之間在時間上沒有依賴性，也就是說當發送者發送了消息以後，無論接收者有沒有正在運行，它不會影響到消息被髮送到隊列

接收者在成功接收消息以後需向隊列應答成功

2.Publish/Subscribe(Pub/Sub) 發佈訂閱模式

Pub/Sub模式包含三個角色：主題（Topic），發佈者（Publisher），訂閱者（Subscriber）。

多個發佈者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。

​

Pub/Sub的特色：

每一個消息能夠有多個消費者

發佈者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須建立一個訂閱以後，才能消費發佈者的消息

爲了消費消息，訂閱者必須保持運行的狀態

爲了緩和這樣嚴格的時間相關性，JMS容許訂閱者建立一個可持久化的訂閱。這樣，即便訂閱者沒有被激活（運行），它也能接收到發佈者的消息。

消息確認機制

AUTO_ACKNOWLEDGE = 1     自動確認
直接使用receive方法

CLIENT_ACKNOWLEDGE = 2     客戶端手動確認

經過消息的acknowledge 方法確認消息

DUPS_OK_ACKNOWLEDGE = 3  自動批量確認

  該選擇只是會話遲鈍第確認消息的提交。若是JMS provider 失敗，那麼可能會致使一些重複的消息。若是是重複的消息，那麼JMS provider 必須把消息頭的JMSRedelivered 字段設置爲true。

SESSION_TRANSACTED = 0    事務提交併確認
複製代碼