ActiveMQ簡介與安裝

                                                      

1. ActiveMQ簡介

　　ActiveMQ是一種開源的，實現了JMS1.1規範的，面向消息(MOM)的中間件，爲應用程序提供高效的、可擴展的、穩定的和安全的企業級消息通訊。ActiveMQ使用Apache提供的受權，任何人均可以對其實現代碼進行修改。

　　ActiveMQ的設計目標是提供標準的，面向消息的，可以跨越多語言和多系統的應用集成消息通訊中間件。ActiveMQ實現了JMS標準並提供了不少附加的特性。這些附加的特性包括，JMX管理（java Management Extensions，即java管理擴展），主從管理（master/salve，這是集羣模式的一種，主要體如今可靠性方面，當主中介（代理）出現故障，那麼從代理會替代主代理的位置，不至於使消息系統癱瘓）、消息組通訊（同一組的消息，僅會提交給一個客戶進行處理）、有序消息管理（確保消息可以按照發送的次序被接受者接收）。消息優先級（優先級高的消息先被投遞和處理）、訂閱消息的延遲接收（訂閱消息在發佈時，若是訂閱者沒有開啓鏈接，那麼當訂閱者開啓鏈接時，消息中介將會向其提交以前的，其未處理的消息）、接收者處理過慢（可使用動態負載平衡，將多數消息提交處處理快的接收者，這主要是對PTP消息所說）、虛擬接收者（下降與中介的鏈接數目）、成熟的消息持久化技術（部分消息須要持久化到數據庫或文件系統中，當中介崩潰時，信息不會丟失）、支持遊標操做（能夠處理大消息）、支持消息的轉換、經過使用Apache的Camel能夠支持EIP、使用鏡像隊列的形式輕鬆的對消息隊列進行監控等。

　　客戶端API：ActiveMQ提供了多種客戶端可訪問的API，包括Java、C/C++，.NET，Perl、PHP、Python、Ruby等。固然，ActiveMQ中介必須運行在Java虛擬機中，可是使用它的客戶端可使用其餘的語言來實現。

　　中介集羣：多個ActiveMQ中介能夠一塊兒協同工做，來完成某項複雜的工做，這被稱爲網絡型中介（network of brokers），這種類型的中介將會支持多種拓撲類型。

2. 爲何使用ActiveMQ　

　　在設計分佈式應用程序時，應用程序間的耦合（或稱集成）方式很重要。耦合意味着兩個或者多個應用程序或系統的相互依賴關係。一種簡單的方式是在全部的應用程序中從架構上設計他們與其餘應用程序間的交叉實現。這樣必然致使，一個應用程序的改變，直接致使另外一個應用程序的改變。按照這種方式集成的應用是一種緊耦合的應用。一個應用的改變不會影響到其餘應用的集成方式被稱爲是鬆耦合的集成方式。簡單的說，鬆耦合應用程序集成可以更容易的處理不可預見的應用變化。

　　像COM、CORBA、DCE和EJB等應用技術使用RPC（Remote Procedural Calls，即遠程過程調用）屬於緊耦合技術。使用RPC，一個應用程序調用另外一個應用程序，調用者必須阻塞，直到被調用者執行結束返回結果信息爲止。下圖給出了這種緊耦合技術的描述：

 

　　許多系統架構使用RPC，而且得到了巨大的成功，可是，緊耦合的架構有着天生的缺陷。首先，這種架構將會形成系統維護管理上的巨大消費，由於，即便是很小的改動，極可能會波及到整個系統。其次，因爲調用者必須阻塞式的等待被調用者返回，若是被調用者處理過程複雜，將會嚴重影響調用者的執行效率和資源使用率。此外，若是調用失敗，整個架構即失敗。

　　下圖給出一種鬆耦合的方式，進行架構設計：

　　應用程序1向消息中介（MOM）發送一條消息，極可能一段時間以後，應用程序2調用MOM來收取消息。任何一個應用程序都不知道對方是否存在也不須要阻塞等待。這種通訊方式大大縮減了維護開銷，由於對於一個應用程序的修改，會對其餘應用程序影響極小。

　　ActiveMQ就是採用了上面提到的鬆耦合方式，所以，咱們常常說應用程序發送消息僅僅是觸發後忘卻。應用程序將消息發送給ActiveMQ而並不關心什麼時間以何種方式消息投遞給接收者。一樣的，消息接收者也不會關心消息來源於哪裏和消息是怎樣投遞給ActiveMQ的。對於多語言編寫的複雜應用環境中，容許客戶端使用不一樣的編程語言甚至不一樣的消息包裝協議。ActiveMQ做爲消息的中間件，容許複雜的多語言應用程序以一種一步的方式集成和交互。因此說，ActiveMQ是一種好的，提供鬆散耦合的，可以爲多語言交叉應用提供集成的中間件。

3. 什麼狀況下使用ActiveMQ

　　正如前面提到的，緊耦合應用系統存在許多問題，可是，要將緊耦合系統重構成鬆耦合系統是一件值得但比較繁瑣的事情。使用鬆耦合的主要優點體如今將同步改成異步。使用異步通訊，應用程序將從接收者反饋的等待中解放出來，其餘的任務能夠獲得執行，這樣提升了應用程序的效率。

　　只要是兩個應用程序間須要通訊的狀況，均可以考慮使用JMS，不論這種通訊是在本地的（就是通訊的兩個應用程序在同一臺主機上），仍是分佈在不一樣機器上。儘管是在同一個主機上的兩個應用程序須要通訊也可使用ActiveMQ。ActiveMQ能夠確保消息投遞成功並採用異步方式通訊。

　　多個須要通訊的應用程序在同一個機器上的狀況下，您能夠考慮在執行機上獨立運行ActiveMQ或者將ActiveMQ嵌入到Java應用服務中。不管採用哪一種方式，均可以確保應用程序可以發送和接收消息。您能夠選擇訂閱模式（pub/sub）或者採用PTP（point to point）模式，這兩種模式都無需等待執行反饋信息。每個應用程序均可以簡單的將消息發送給ActiveMQ，而後繼續作其餘的工做；應用程序無需阻塞式等待消息的返回。

　　對於分佈在多臺主機上的應用程序來講，可使用多種佈置策略。主要包括單一ActiveMQ實例和多ActiveMQ實例。單一ActiveMQ實例是一個簡單解決方案。全部的應用程序都向同一個ActiveMQ中介發送和接收消息，這與上面提到的單機多服務雷同。單一的ActiveMQ能夠佈置到一臺單獨的主機上，也能夠和其中的一些服務佈置在一塊兒。重要的是，全部的應用必須可以直接與ActiveMQ中介進行交互，因此，你必須考慮到你的網絡設計。

　　第二種狀況比較複雜，可是有ActiveMQ來負責遠程通訊，而不是應用程序自身。在這種場景下，每個應用程序都會實例化一個ActiveMQ（不管是嵌入式的仍是獨立式的），應用程序從其本地的ActiveMQ發送和接收消息。以後這些ActiveMQ實例將會以一種聯合的方式協同工做。消息將會基於每個應用的要求在多個ActiveMQ中介間傳遞到遠程的處理者。在ActiveMQ中，這種模式被稱爲netWork of brokers。採用這種模式對於處理大量的ActiveMQ消息是可行的，可是，咱們每每須要減輕網絡拓撲的複雜性，這樣直接將消息投遞到遠程接收者的ActiveMQ是不可行的。在後一種狀況下，不一樣的協議使用可使ActiveMQ更輕鬆的傳遞消息。

4. ActiveMQ模型

1）點對點(隊列)模型

Point to Point

在點對點或隊列模型下，一個生產者向一個特定的隊列發佈消息，一個消費者從該隊列中讀取消息。這裏，生產者知道消費者的隊列，並直接將

消息發送到消費者的隊列。這種模式被歸納爲：

• 只有一個消費者將得到消息

• 生產者不須要在接收者消費該消息期間處於運行狀態，接收者也一樣不須要在消息發送時處於運行狀態。

• 每個成功處理的消息都由接收者簽收

2）發佈/訂閱模型

Publisher/Subscriber Model

發佈者／訂閱者模型支持向一個特定的消息主題發佈消息。0或多個訂閱者可能對接收來自特定消息主題的消息感興趣。在這種模型下，發佈者和

訂閱者彼此不知道對方。這種模式比如是匿名公告板。這種模式被歸納爲：

• 多個消費者能夠得到消息

• 在發佈者和訂閱者之間存在時間依賴性。發佈者須要創建一個訂閱（subscription），以便客戶可以購訂閱。訂閱者必須保持持續的活狀態以接收消息，除非訂閱者創建了持久的訂閱。在那種狀況下，在訂閱者未鏈接時發佈的消息將在訂閱者從新鏈接時從新發布。

5. ActiveMQ下載和安裝

　　ActiveMQ官方網站：http://activemq.apache.org/

　　我選擇的是apache-activemq-5.10.0-bin.tar.gz版本，放在/usr/local目錄下

（2）解壓

　　tar -xzvf apache-activemq-5.10.0-bin.tar.gz

　　

（3）ActiveMQ全部的配置都在conf目錄下

　　

（4）進入bin目錄啓動

　　

　　

附：參考資料

　　（1）ActiveMQ簡介：http://www.cnblogs.com/kgdxpr/p/3381974.html

　　（2）ActiveMQ P2P版的HelloWorld：https://my.oschina.net/chaun/blog/404615