JMS（Java Messaging Service）是Java平臺上有關面向消息中間件的技術規範，其實是一套api，它便於消息系統中的Java應用程序進行消息交換,而且經過提供標準的產生、發送、接收消息的接口簡化企業應用的開發，消息中間件是這個規範的一個具體實現。前端

JMS規範中的消息

JMS 消息由如下三部分組成：數據庫

· 消息頭。每一個消息頭字段都有相應的getter 和setter 方法。
· 消息屬性。若是須要除消息頭字段之外的值，那麼可使用消息屬性。
· 消息體。JMS 定義的消息類型有TextMessage、MapMessage、BytesMessage、StreamMessage 和 ObjectMessage。

JMS消息模型

Point-to-Point(P2P) / 點對點api

消息經過稱爲隊列的一個虛擬通道來進行交換。隊列是生產者發送消息的目的地和接受者消費消息的消息源。服務器

每條消息通僅會傳送給一個接受者。可能會有多個接受者在一個隊列中偵聽，可是每一個隊列中的消息只能被隊列中的一個接受者消費。網絡

消息存在前後順序。一個隊列會按照消息服務器將消息放入隊列中的順序，把它們傳送給消費者當消息已被消費時，就會從隊列頭部將它們刪除。架構

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

發送者發送了消息以後，無論接收者有沒有正在運行，它不會影響到消息被髮送到隊列異步

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

若是但願發送的每一個消息都應該被成功處理的話，使用這個P2P模式。spa

一、消息生產者（發佈）將消息發佈到topic中，同時有多個消息消費者（訂閱）消費該消息。和點對點方式不一樣，發佈到topic的消息會被全部訂閱者消費。

二、若是你但願發送的消息能夠不被作任何處理、或者被一個消息者處理、或者能夠被多個消費者處理的話，那麼能夠採用topic模型

常見的消息中間件

1、異步處理

場景說明：用戶註冊後，須要發註冊郵件和註冊短信。傳統的作法有兩種1.串行的方式；2.並行方式。

串行方式：將註冊信息寫入數據庫成功後，發送註冊郵件，再發送註冊短信。以上三個任務所有完成後，返回給客戶端。

（2）並行方式：將註冊信息寫入數據庫成功後，發送註冊郵件的同時，發送註冊短信。以上三個任務完成後，返回給客戶端。與串行的差異是，並行的方式能夠提升處理的時間。

假設三個業務節點每一個使用50毫秒鐘，不考慮網絡等其餘開銷，則串行方式的時間是150毫秒，並行的時間多是100毫秒。

小結：如以上案例描述，傳統的方式系統的性能（併發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？

引入消息隊列，將不是必須的業務邏輯，異步處理。

按照以上約定，用戶的響應時間至關因而註冊信息寫入數據庫的時間，也就是50毫秒。註冊郵件，發送短信寫入消息隊列後，直接返回，所以寫入消息隊列的速度很快，基本能夠忽略，所以用戶的響應時間多是50毫秒。所以架構改變後，系統的吞吐量提升到每秒20 QPS。比串行提升了3倍，比並行提升了兩倍。

2、應用解耦

場景說明：用戶下單後，訂單系統須要通知庫存系統。傳統的作法是，訂單系統調用庫存系統的接口。

傳統模式的缺點：

1）假如庫存系統沒法訪問，則訂單減庫存將失敗，從而致使訂單失敗；

2）訂單系統與庫存系統耦合；

如何解決以上問題呢？引入應用消息隊列後的方案

訂單系統：用戶下單後，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功。

庫存系統：訂閱下單的消息，採用拉/推的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操做。

假如：在下單時庫存系統不能正常使用。也不影響正常下單，由於下單後，訂單系統寫入消息隊列就再也不關心其餘的後續操做了。實現訂單系統與庫存系統的應用解耦。

3、流量削峯

流量削峯也是消息隊列中的經常使用場景，通常在秒殺或團搶活動中使用普遍。

應用場景：秒殺活動，通常會由於流量過大，致使流量暴增，應用掛掉。爲解決這個問題，通常須要在應用前端加入消息隊列：能夠控制活動的人數；能夠緩解短期內高流量壓垮應用。

用戶的請求，服務器接收後，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面；秒殺業務根據消息隊列中的請求信息，再作後續處理。

4、日誌處理

日誌處理是指將消息隊列用在日誌處理中，好比Kafka的應用，解決大量日誌傳輸的問題。架構簡化以下：

日誌採集客戶端，負責日誌數據採集，定時寫入Kafka隊列：Kafka消息隊列，負責日誌數據的接收，存儲和轉發；日誌處理應用：訂閱並消費kafka隊列中的日誌數據。