? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

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

轉載于:https://www.cnblogs.com/xiaobingqianrui/p/9411454.html

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的ActiveMQ简介与安装的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。