一、為什麼使用訊息中介軟體
1、消除高併發訪問高峰，加快網站的響應速度
2、非同步處理
3、應用解耦
4、訊息通訊四個場景

二、JMS簡介：
　　JMS即Java訊息服務（Java Message Service）應用程式介面是一個Java平臺中關於面向訊息中介軟體（MOM）的API，用於在兩個應用程式之間，或分散式系統中傳送訊息，進行非同步通訊。Java訊息服務是一個與具體平臺無關的API，絕大多數MOM提供商都對JMS提供支援。

2.1 定義：
　　JMS（Java Messaging Service）是Java平臺上有關面向訊息中介軟體(MOM)的技術規範，它便於訊息系統中的Java應用程式進行訊息交換,並且通過提供標準的產生、傳送、接收訊息的介面簡化企業應用的開發，翻譯為Java訊息服務。

2.2 簡介：
　　JMS是一種與廠商無關的 API，用來訪問訊息收發系統訊息。它類似於JDBC(Java DatabaseConnectivity)：這裡，JDBC 是可以用來訪問許多不同關係資料庫的 API，而 JMS 則提供同樣與廠商無關的訪問方法，以訪問訊息收發服務。許多廠商目前都支援JMS，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ，這只是幾個例子。 JMS 使您能夠通過訊息收發服務（有時稱為訊息中介程式或路由器）從一個 JMS 客戶機向另一個JMS客戶機發送訊息。訊息是 JMS 中的一種型別物件，由兩部分組成：報頭和訊息主體。報頭由路由資訊以及有關該訊息的元資料組成。訊息主體則攜帶著應用程式的資料或有效負載。根據有效負載的型別來劃分，可以將訊息分為幾種型別，它們分別攜帶：簡單文字(TextMessage)、可序列化的物件 (ObjectMessage)、屬性集合 (MapMessage)、位元組流 (BytesMessage)、原始值流 (StreamMessage)，還有無有效負載的訊息 (Message)。

2.3 jms介面：
MS只給出介面，然後由具體的中介軟體去實現，比如ActiveMQ就是實現了JMS的一種Provider，還有阿里巴巴的RocketMQ（後續專題中在為大家介紹）。這些訊息中介軟體都符合JMS規範。說起規範，自然要定義一些術語：

Provider/MessageProvider：生產者
Consumer/MessageConsumer：消費者
PTP：Point To Point：點對點通訊訊息模型
Pub/Sub：Publish/Subscribe：釋出訂閱訊息模型
Queue：佇列，目標型別之一，和PTP結合
Topic：主題，目標型別之一，和Pub/Sub結合
ConnectionFactory：連線工廠，JMS用它建立連線
Connnection：JMS Client到JMS Provider的連線
Destination：訊息目的地，由Session建立
Session：會話，由Connection建立，實質上就是傳送、接受訊息的一個執行緒，因此生產者、消費者都是Session建立的

三、MQ簡介
　　MQ全稱為Message Queue, 訊息佇列（MQ）是一種應用程式對應用程式的通訊方法。應用程式通過寫和檢索出入列隊的針對應用程式的資料（訊息）來通訊，而無需專用連線來連結它們。訊息傳遞指的是程式之間通過在訊息中傳送資料進行通訊，而不是通過直接呼叫彼此來通訊，直接呼叫通常是用於諸如遠端過程呼叫的技術。排隊指的是應用程式通過佇列來通訊。佇列的使用除去了接收和傳送應用程式同時執行的要求。其中較為成熟的MQ產品有IBMWEBSPHERE MQ。

3.1 MQ特點：
　　MQ的消費-生產者模型的一個典型的代表，一端往訊息佇列中不斷的寫入訊息，而另一端則可以讀取或者訂閱佇列中的訊息。MQ和JMS類似，但不同的是JMS是SUN JAVA訊息中介軟體服務的一個標準和API定義，而MQ則是遵循了AMQP協議的具體實現和產品。

使用場景：
　　在專案中，將一些無需即時返回且耗時的操作提取出來，進行了非同步處理，而這種非同步處理的方式大大的節省了伺服器的請求響應時間，從而提高了系統的吞吐量。

3.2 JMS和MQ的關係：
　　JMS是一個用於提供訊息服務的技術規範，它制定了在整個訊息服務提供過程中的所有資料結構和互動流程。而MQ則是訊息佇列服務，是面向訊息中介軟體（MOM）的最終實現，是真正的服務提供者；MQ的實現可以基於JMS，也可以基於其他規範或標準。
支援JMS的開源MQ：
目前選擇的最多的是ActiveMQ。
ActiveMQ 是Apache出品，最流行的，能力強勁的開源訊息匯流排。ActiveMQ 是一個完全支援JMS1.1和J2EE 1.4規範的 JMS Provider實現,儘管JMS規範出臺已經是很久的事情了,但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。

3.3 主要特點：

1. 多種語言和協議編寫客戶端。語言: Java, C, C++, C#, Ruby, Perl, Python, PHP。應用協議: OpenWire,Stomp REST,WSNotification,XMPP,AMQP
2. 完全支援JMS1.1和J2EE 1.4規範 (持久化,XA訊息,事務)
3. 對Spring的支援,ActiveMQ可以很容易內嵌到使用Spring的系統裡面去,而且也支援Spring2.0的特性
4. 通過了常見J2EE伺服器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的測試,其中通過JCA 1.5 resource adaptors的配置,可以讓ActiveMQ可以自動的部署到任何相容J2EE 1.4 商業伺服器上
5. 支援多種傳送協議:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
6. 支援通過JDBC和journal提供高速的訊息持久化
7. 從設計上保證了高效能的叢集,客戶端-伺服器,點對點
8. 支援Ajax
9. 支援與Axis的整合
10. 可以很容易得呼叫內嵌JMS provider,進行測試
11. ActiveMQ速度非常快；一般要比jbossMQ快10倍。

3.4 優點：
　　是一個快速的開源訊息元件(框架)，支援叢集，同等網路，自動檢測，TCP，SSL，廣播，持久化，XA，和J2EE1.4容器無縫結合，並且支援輕量級容器和大多數跨語言客戶端上的Java虛擬機器。訊息非同步接受，減少軟體多系統整合的耦合度。訊息可靠接收，確保訊息在中介軟體可靠儲存，多個訊息也可以組成原子事務。

3.5 缺點：
　　ActiveMQ預設的配置效能偏低，需要優化配置，但是配置檔案複雜，ActiveMQ本身不提供管理工具；示例程式碼少；主頁上的文件看上去比較全面，但是缺乏一種有效的組織方式，文件只有片段，使用者很難由淺入深進行了解，二、文件整體的專業性太強。在研究階段可以通過查maillist、看Javadoc、分析原始碼來了解。

四、ActiveMQ應用場景

4.1 不同語言應用整合
ActiveMQ 中介軟體用Java語言編寫，因此自然提供Java客戶端 API。但是ActiveMQ 也為C/C++、.NET、Perl、PHP、Python、Ruby 和一些其它語言提供客戶端。在你考慮如何整合不同平臺不同語言編寫應用的時候，ActiveMQ 擁有巨大優勢。在這樣的例子中，多種客戶端API通過ActiveMQ 傳送和接受訊息成為可能，無論使用的是什麼語言。此外，ActiveMQ 還提供交叉語言功能，該功能整合這種功能，無需使用遠端過程呼叫（RPC）確實是個優勢，因為訊息協助應用解耦。

4.2 作為RPC的替代
使用RPC同步呼叫的應用十分普遍。假設大多數客戶端伺服器應用使用RPC，包括ATM、大多數WEB應用、信用卡系統、銷售點系統等等。儘管很多系統很成功，但是轉換使用非同步訊息可以帶來很多好處，而且也不會放棄響應保證。使用同步請求的系統在規模上有較大的限制，因為請求會被阻塞，從而導致整個系統變慢。如果使用非同步訊息替代，可以很容易增加額外的訊息接收者，使得訊息能被併發消耗，從而加快請求處理。當然，你的系統應用間應該是解耦的。

4.3 應用之間解耦
正如之前討論的，緊耦合架構可以導致很多問題，尤其是如果他們是分佈的。鬆耦合架構，在另一方面，證實了更少的依賴性，能夠更好地處理不可預見的改變。不僅可以在系統中改變元件而不影響整個系統，而且元件互動也相當的簡單。相比使用同步的系統（呼叫者必須等待被呼叫者返回資訊），非同步系統（呼叫方傳送訊息後就不管，即fire-and-forget）能夠給我們帶來事件驅動架構（event-driven architecture EDA）。

4.4 作為事件驅動架構的主幹
解耦，非同步架構的系統允許通過代理器自己配置更多的客戶端，記憶體等（即vertical scalability）來擴大系統，而不是增加更多的代理器（即horizontal scalability）。考慮如亞馬遜這樣繁忙的電子商務系統。當用戶購買物品，事實上系統需要很多步驟去處理，包括下單，建立發票，付款，執行訂單，運輸等。但是使用者下單後，會立即返回“謝謝你下單”的介面。不只是沒有延遲，而且使用者還會受到一封郵件表明訂單已經收到。在亞馬遜下單的例子就是一個多步處理的例子。每一步都由單獨的服務去處理。當用戶下單是，有一個同步的體積表單動作，但整個處理流程並不通過瀏覽器同步處理。相反地，訂單馬上被接受和反饋。而剩下的步驟就通過非同步處理。如果在處理過程中出錯，使用者會通過郵件收到通知。這樣的非同步處理能提供高負載和高可用性。

4.5 提高系統擴充套件性
很多使用事件驅動設計的系統是為了獲得高可擴充套件性，例如電子商務，政府，製造業，線上遊戲等。通過非同步訊息分開商業處理步驟給各個應用，能夠帶來很多可能性。考慮設計一個應用來完成一項特殊的任務。這就是面向服務的架構（service-oriented architecture SOA）。每一個服務完成一個功能並且只有一個功能。應用就通過服務組合起來，服務間使用非同步訊息和最終一致性。這樣的設計便可以引入一個複雜事件處理概念（complex event processing CEP）。使用CEP，部件間的互動可以被記錄追蹤。在非同步訊息系統中，可以很容易在部件間增加一層處理。

五、通訊模式
5.1 點對點(queue)
》一個訊息只能被一個服務接收
》訊息一旦被消費，就會消失
》如果沒有被消費，就會一直等待，直到被消費
》多個服務監聽同一個消費空間，先到先得
詳解：這個特點的原理是這樣的，在activeMQ
5.2 釋出/訂閱模式(topic)
　　》一個訊息可以被多個服務接收
　　 》訂閱一個主題的消費者，只能消費自它訂閱之後釋出的訊息。
　　 》消費端如果在生產端傳送訊息之後啟動，是接收不到訊息的，除非生產端對訊息進行了持久化(例如廣播，只有當時聽到的人能聽到資訊)

ps: 程式碼在下一章==>ActiveMQ（二、程式碼實現）
https://blog.csdn.net/qq_16055765/article/details/83309422