轉自：http://www.jarorwar.com/407
讀書筆記(一)——基礎概念
1、JMS：JMS是java message service的縮寫，就是java的消息服務。JMS是Java消息服務的一個規範的定義，並不是具體的實現。JMS規範的詳細文檔參考 http://vdisk.weibo.com/s/386lO
2、MQ：MQ其實是message queue的縮寫，簡單的翻譯過來就是消息隊列。
3、Active-MQ：是apache的一款java實現的開源的JMS1.1規範的實現。
MQ的作用：
1、應用程序之間的通信
2、應用程序的集成
Active-MQ：
提供了應用程序之間松耦合集成和異步通信。當然它也可以支持同步通信
支持如下多的協議：http,https ,ip多重廣播,ssl協議,stomp協議,tcp協議，udp協議xmpp等等
active-mq可以根據你的需求定製安全機制，同時，它的持久化機制也是有豐富的可選擇性。
你可以選擇使用active-mq默認的kahadb作爲持久化，也可以通過jdbc來使用數據庫進行持久化。
activemq自身支持簡單的授權和認證方式，它是通過properties文件來實現。
支持java–可以與tomcat，jetty，jboss等服務器集成起來用（非單獨實例進行運行）
可以支持集羣，管理控制簡單，可有使用jmx，jconsole，webconsole等
總之，上面都是說active-mq的好了！好不好只有用了知道！筆者接觸到另外一款比較成熟的MQ是rabbit MQ，可以說比active-mq成熟吧，使用elang語言實現的，有興趣的話可以研究。當然作爲java程序，active-mq是首選了。如果有錢的話可以使用ibm的mq。。
下一節介紹下MQ的使用場景！
學習筆記（二）——引用場合
看了好多好大一段英文，主要闡述了MQ應當用於解耦的場合。例如調用rpc的地方可以改用MQ，MQ主要用來實現一種松耦合(loosely coupled)的架構，圖如下：
簡單對上圖說明一下，
application A和application B通過 消息中間件進行通信，這樣A的改動不會影響到B，B的改動也不會影響到A。就是這麼簡單！同時，程序的任何一部分被停掉（take down）做維護，而不會影響到整個系統。
This means that any segment of this architecture can be taken down for maintenance at any time without taking down the entire system
又是一段誇的話，不翻譯了，其中有一句很重要。紅色標記。
So ActiveMQ provides an incredible amount of flexibility in application architec-
ture, allowing the concepts surrounding loose coupling to become a reality. ActiveMQ
also supports the request/reply paradigm of messaging if a completely asynchronous
style of messaging isn’t possible for a given use case. But when should ActiveMQ be
used to introduce these benefits?
上面紅色標記部分，說了，如果異步模型不能夠支持使用場景的話，ActiveMQ同樣支持基於 “request/response(reply)”這種模式！
上面那麼多隻是說明了Why to use！下面說明When to 。。
When to use ActiveMQ
1、Heterogeneous application integration：異構應用程序的集成（整合），例如，不同語言寫的程序，java、c、c++，
2、As a replacement for RPC：作爲RPC程序的替代
3、To loosen the coupling between applications：應用程序之間的解耦合
4、As the backbone of an event-driven architecture：做爲事件驅動架構的一個事件分發的主線（個人理解翻譯），此處舉的例子是亞馬遜的購物：
When a user makes a purchase on
Amazon, there are quite a few separate stages through which that order must
travel including order placement, invoice creation, payment processing, order
fulfillment, shipping, and more. But when a user actually places an order, the
user is immediately taken to a page stating, “Thanks for your order.” Not only
that, but without delay, the user also receives an email stating that the order was
received.
The order placement process that’s employed by Amazon is a good
example of the first stage in a much larger set of asynchronous processes. Each
stage of the order is handled discretely by a separate service. When the user
places the order, there’s a synchronous call to submit the order, but the entire
order process doesn’t take place behind a synchronous call via the web browser.
Instead, the order is accepted and acknowledged immediately. The rest of the
steps in the process are handled asynchronously. If a problem occurs that
prevents the process from proceeding, the user is notified via email. Such asyn-
chronous processes are what afford massive scalability and high availability.
意思就是說，在用戶的購物過程中有很多獨立的過程，如果採用同步的過程，一個步驟失敗，可能導致其它一些過程的失敗。但是採用mq的異步模型，不會發生這樣的事情。例如給用戶發郵件失敗，則不會影響開發票。
5、To improve application scalability：改善程序的課擴展性
以上是MQ使用的一些場景，按照本人的理解，mq可以解耦合，mq可以用於異構系統，mq可以……貌似mq是一個解決異步的銀彈！
理解不對的地方請大家指點
學習筆記（三）——MQ安裝
依賴軟件：Java
下載windows下的zip版本即可，解壓後，目錄結構如下：
bin—-ActiveMQ的二進/制可執行文件，其中啓動MQ的腳本就在裏面。
conf—–很明顯，跟配置相關的文件都放在這裏了
data—-持久化文件和日誌存放的目錄
example—一些自帶的例子
lib——-ActiveMQ需要（依賴）的所有jar文件
webapps—–ActiveMQ的admin的web控制檯和一些基於web的demo
activemq-all-{version}.jar—mq的jar包，可以用來作爲嵌入式使用
WebConsole-README.txt—web控制檯的一些信息
其餘的不解釋了。有興趣看一哈子。
啓動MQ:
如果配置好了java的環境後，進入上面的bin目錄，直接雙擊：activemq.bat即可。
如上信息，說明啓動成功。
訪問WebConsole：http://localhost:8161/admin/ 可以看到web控制檯
這時候，MQ可以通過TCP協議的61616端口進行鏈接
到此，mq的環境搭建完畢。當然如果你有ant的話，你可以用ant run一下examples下面的程序，本文不打算在此處演示。等到後面，自然會涉及到相應的程序的。
學習筆記(四)——MOM的一些特性
MOM：面向消息的中間件，即Message-oriented middleware的縮寫。
MOM的一些特性：
MOMs added welcome additional features to enterprise messaging that weren’t
previously possible when systems were tightly coupled—features such as message per-
sistence, robust communication over slow or unreliable connections, complex mes-
sage routing, message transformation, and much more. Message persistence helps to
mitigate slow or unreliable connections made by senders and receivers; or in a situa-
tion where a receiver simply fails, it won’t affect the state of the sender. Complex mes-
sage routing opens up a huge number of possibilities, including delivering a single
message to many receivers, message routing based on properties or the content of a
message, and so forth. Message transformation allows two applications that don’t han-
dle the same message format to now communicate via a custom message format that’s
transformed on the fly.
下面是一個JMS和MQ之間的關係圖：
應該在第一里面寫的，現在記在此處
下面說一下一個JMS程序的創建步驟
1 Acquire a JMS connection factory
2 Create a JMS connection using the connection factory
3 Start the JMS connection
4 Create a JMS session from the connection
5 Acquire a JMS destination
6 Create a JMS producer, OR
a Create a JMS producer
b Create a JMS message and address it to a destination
7 Create a JMS consumer
a Create a JMS consumer
b Optionally register a JMS message listener
8 Send or receive JMS message(s)
9 Close all JMS resources (connection, session, producer, consumer, and so forth)
學習筆記（六）——ActiveMQ Cluster
Cluster一般都是用戶HA（高可用性）環境。
ActiveMQ支持兩種類型的集羣：shared nothing 和shared storage（這是 AIA上這樣分的），官方分爲三種，如下圖片所示，其實無論怎麼分，在意思上是一樣的。
以上圖片是官方的英文說明，此處我簡單說一下：
1、pure master-slave:當master出現故障，則slave自動充當master。
依賴條件：無
優點：配置簡單，無其它依賴，沒有核心故障點
缺點： 只能有一個slave節點，master失敗後需要手動重啓以恢復主節點。
2、Shared store：共享存儲設備，這包括上圖中的最後兩個，其共同點是節點共享了同一個存儲數據（數據庫或者文件系統）
依賴條件：共享文件系統或者關係型數據庫，例如mysql
優點：可以有多個slave（大於等於1個），主節點會自動恢復。
缺點：依賴文件系統或者數據庫，配置相對來說比較複雜。
下面我們將會分別對這三種情況舉例進行說明。
（七）——Pure Master—Slave配置測試
此處我們來討論一下Pure Master—Slave的配置方法和相關的測試。
Pure模式的M-S部署，相當於部署了兩套相互獨立的ActiveMQ實例，它們擁有各自的存儲系統。這也是提供HA的最簡單的一種方式。此種方式只有兩個MQ實例。
此種配置方式的話，Master端不用做任何配置，只要在Slave端指定Master即可。這種配置的話，Master的所有數據和消息都會被複制一份到Slave，這些複製發生在Master處理這些消息之前。如下圖所示：
Slave 會在啓動的時候連接到Master，因此，先要運行Master，然後才能啓動Slave。啓動後的Salve是不會處理任何消息分發的。它自身也不會初始化任何網絡連接，知道master失敗。一個失敗的master可以被Salve的連通性檢測到。
這種模式下，生產者在發送消息後處於一種等待狀態，只有在master確認收到消息後，生產者纔可以發送下一條消息給master。然而，master並不是一收到消息後，就立刻發送一個收條給生產者，而是當將此消息成工複製到slave後才，並且master處理了此消息後才發送給生產者。
上面翻譯的比較繞口，簡單來說就是這樣子：
P(producer)發送一條消息到M（master），M會複製一份消息到S（slave），同時M會對消息進行相應的處理，例如保存消息到數據庫，分發消息到相應的訂閱者。只有完成這些操作之後，M纔會發送一個“收條”給P，這時候P纔可以繼續發送下一條消息給M。
當Master失敗後，Slave有以下兩種選擇：
1、關閉自己（Slave），因此，這種情況下，Slave 僅僅是對Master的狀態進行了一個保存。在這種情況下，管理員需要手動將slave配置成master，同時配置另外一個新的實例作爲slave。（這樣做貌似沒有什麼太大的意思。）
2、Slave可以啓動自身的transports 和network connection，這時候，Slave會自動承擔起處理消息的任務，成爲新的Master。
此種方式的配置。客戶端需要通過以下方式去鏈接MQ：
failover://(tcp://masterhost:61616,tcp://slavehost:61616)?randomize=false
這種配置是有一定缺陷的：
A、master只會複製slave鏈接上master以後的消息到slave，如果在slave沒有連接到master之前，有消息沒有處理，這樣子是不會被master複製到slave的。你可以使用waitForSlave屬性去設置，這個屬性會強迫master在slave沒有連接上之前不要接受任何客戶端的鏈接。（這種做法貌似很不地道哈。。）
B、另外一個限制就是Master只允許有一個Slave，而Slave自身不可能有一個其它的Slave。這樣當Master倒下之後，Slave就成了Master了。這樣。當你配置好Master之後，你需要關閉你的Slave，並且從Slave中拷貝一份data到Master。然後啓動Master，然後啓動Slave。以重新恢復master-slave的結構。這樣就需要停機。不能完全在不停機的情況下進行處理了。
如果你的應用停機是可以接受的，那麼就可以選用這種方式。
其實上面的做法有些複雜，簡單的實踐是：在master宕機後，slave成了新的master，這時候，將舊的master配置成一個slave，將舊的slave配置成新的master，然後重新啓動新的master和新的slave即可。（只需事先寫好兩份配置文件，在需要的時候重命名一下即可。當然這種做法也是少不了停機的，只是相對複製data數據來說簡單多了。）
上面說的天花亂墜的，下面，給大家說一下如何配置。
在我本地有兩個mq，如下圖所示：一個mster，一個slave。
master不用修改，直接啓動即可。
修改slave的配置文件：
修改activemq.xml文件如下所示：
<services>
<masterConnector remoteURI="tcp://localhost:61616"/>
</services><transportConnectors>
<transportConnector name="openwire" uri="tcp://0.0.0.0:61617"/>
</transportConnectors>
remoteURI:指的是master的路徑
transportConnector name="openwire" uri="tcp://0.0.0.0:61617" slave transport的路徑。
完全文件，請參考http://vdisk.weibo.com/s/3ajLO（下載後解壓。威盤今天有點問題，貌似不能對xml文件創建分享鏈接，所以壓縮了下）。
配置完成後，啓動Master：界面如下，啓動成功：
等待Master啓動完成後，啓動Slave：
ok，slave也啓動成功。
注意：如果啓動失敗的情況下，一定要去看看日誌，如下圖文件
在日誌裏會記錄清楚一切的。另外一個建議就是不要直接雙擊activemq.bat文件。在cmd下運行，這樣也可以看到錯誤信息，如果雙擊的話，就會一閃而過了。
ok，木有任何問題，那麼我們開始run我們的程序。
程序簡單說明。一個producer，一個consumer。producer發送一條消息，consumer接受並打印。
先啓動，程序的生產者是隔1秒，生產一個消息，一共生產100個。這就有足夠長的時間讓我們關閉master，並且觀察consumer是否可以正常輸出消息了。
先啓動消費者。
在消費者輸出第27個消息的時候。我們關閉了master，這時候，可以看到，消費者繼續輸出消息。
並且最終完成了所有消息的消費（輸出），
沒有任何問題。結果符合我們的期望。
但是此時，slave已經是master了。如果要給slave加一個slave加一個master就必須停止slave，然後配置，重啓了。
另外，因爲我做這個測試的時候沒有環境，只有一臺機器，所以能夠聯通。如果是在不同機器上做測試的話，注意防火牆。
ok，這一個配置測試到此完成。如果有說的不明白的地方，歡迎大家留言討論。
測試代碼下載地址：http://vdisk.weibo.com/s/3atqi
（八）——Shared File System Master—Slave配置測試
此處來學習下Shared storage M-S的Shared File System Master-Slave的測試和配置，因爲在一臺機器上，配置這個相對來說比較容易點。
shared storage方式的好處是沒有限制Slave的個數。shared File System M-S其實是基於activemq默認的kahadb完成的，而kahadb的底部是文件系統。當kahadb開始存儲消息的時候，它會獲得一個文件鎖，在這個過程中，如果有任何其它的broker視圖在此時企圖對消息進行保存的話就會被阻止。
這種方式的master-slave模式，是在activemq啓動的時候視圖獲得對存儲文件的鎖，第一個獲得文件鎖的activemq實例將會成爲master，其它就爲slave。當master 宕機後，其它的slave同樣去爭取文件鎖的權限，獲得的將成爲slave，這樣做的好處是在master fail後不用手動配置。只要你有足夠多的slave，或者足夠短的時間內恢復fail的節點。並重新啓動，那麼是不用停機的，真正做的7×24小時的服務。
好吧，我承認，我是邊學習，邊記錄的，看書看到這裏才發現了下面一段很重要的話
There are some technical restrictions regarding where you can run a shared file
system master/slave configuration. The shared file system requires the semantics of a
distributed shared file lock. So if you’re not using a storage area network (SAN), there
are some alternatives such as Network File System (NFS)—available on Mac OS X,
OpenVMS, Microsoft Windows (from third parties), Solaris, and AS/400. If you’re
using Fedora or RedHat Enterprise (5.3 and above), it’s recommended you use the
Global File System (GFS) 2, which requires a cluster locking protocol, such as dlm, the
distributed lock manager, which is a Linux kernel module.
文中同時有言：此種方式的m-s配置性能的瓶頸是在分佈式文件系統的性能上！
此種方式的拓撲結構圖如上圖所示。
這個配置非常簡單，相當簡單，簡單的不能再簡單了（當然只侷限於一臺機器上的windows）。主要的難點就是有一個分佈式的文件系統，如果是Linux你可以使用NFS，如果是linux+windows可以使用samba。至於你更牛逼，有分佈式文件系統，那我就只能羨慕一下，然後告訴你怎麼配置了。
配置：修改所有activemq實例的如下代碼
<persistenceAdapter>
<!– <kahaDB directory="${activemq.base}/data/kahadb"/>–>
<kahaDB directory="D:/mq/data/kahadb"/>
</persistenceAdapter>
directory 只要填寫你的文件系統的路徑即可。注意：填寫前最好訪問下，看存在不。我這裏是本地的所以沒有任何問題。
同時將各個activemq實例的端口修改一下，不然在同一臺機器上衝突，如果你是多臺機器，那麼ok，無所謂了，只要沒有被佔用都行。
測試代碼沿用上一篇文章的代碼，不多解釋：
測試步驟如下：
0、啓動各個實例（此處沒有master和slave之分，系統自動決定是是master，我們不用管，當然爲了做測試，我們先啓動一臺，然後記住這個即可，一會兒要停掉的）
1、啓動消費者
2、啓動生產者
3、停止master，觀察消息是否能夠正常被處理
4、啓動停止的實例，看看消息是否正常
5、停止新的master（就是啓動稍晚的那個實例）
開始啦。。。。。。。。。。。。
1、啓動master
2、啓動slave
看到正常啓動即可。
3、啓動consumer
4、啓動producer
查看consumer的控制檯發現有消息輸出，說明正常
5、停止master
6、發現消息依然能夠被正常處理。
說明在master被停掉之後。slave確實開始接管了master來處理消息。
7、啓動master，看是否能夠正常啓動。
ok，沒有任何問題，啓動成功
8、繼續開始生產者製造消息。
ok，運行正常，沒有任何問題。
9、停止slave，看看master是否正常。
consumer的造消息的機器繼續開啓，供消費者打印消息。
ok，正常，沒有任何問題。說明ok
shared File syste master-slave 測試成功。
oh my god 。。成功的喜悅啊！
測試代碼如下鏈接下載
http://vdisk.weibo.com/s/3atqi
（九）——activemq 配置JDBC方式存儲消息
好吧，我承認前面的兩個測試很順利，心情很好，那麼今天繼續，完成最後一個基於數據庫存儲的集羣環境的搭建。本地使用mysql數據庫存儲消息。
把這個放到最後的原因是複雜.好吧.我承認,巨複雜.在做任何測試前,我們必須將我們的存儲方式換成數據庫方式的存儲.
現在開始吧.
The most common reason why so many organizations choose the JDBC message
store is because they already have expertise administering relational databases. JDBC
persistence is definitely not superior in performance to the aforementioned message
store implementations. The fact of the matter is that many businesses have invested in
the use of relational databases so they prefer to make full use of them
先看一下上面那段話吧.說了很多,最重要的一句是:
JDBC persistence is definitely not superior in performance to the aforementioned message store implementations
嘛意思呢?就是說,jdbc的存儲方式,顯然在性能上不如前面別的存儲方式的實現,其實指的就是 Shared File Syste 和kahadb. 別的亂七八糟的都是廢話!說了企業選擇用數據庫方式存儲的原因.
一旦採用了jdbc的存儲方式,那麼每個mq的實例在啓動的時候都會嘗試獲取數據庫鎖表的鎖.最先獲得這個鎖的將會成爲master,跟文件那個一樣.只是換了中存儲方式.
而其餘的mq實例均處於一種等待的狀態.他們不會接受任何的connection,直到master(最先獲得鎖的那個)失敗.
activemq默認的數據庫是derby.但是支持以下數據庫：
看看吧。支持的真不少！崇拜apache啊！
JDBC消息存儲模式
jdbc消息存儲使用的模式包括了三張數據庫的表。其中有兩張表是用來保存消息的，第三章表是用來進行鎖標識的，目的是一次只有一個mq實例來對數據進行訪問操作。
下面是三張表：
Queues和Topics的消息會被進行處理和存儲到上面ACTIVEMQ_MSGS 這張表中。
上面這張表保存了持續訂閱者的信息和最後一個接受到消息的ID。對於持續訂閱者來說，LAST_ACKED_ID就是一個標識，可以使訂閱者很容易的從上面的ACTIVEMQ_MSGS表中獲取消息
上面這張表是用來加鎖的。防止別的broker在同一時間點來訪訪問上面這兩張表。
上面介紹了jdbc的表結構，那麼下面開始配置jdbc的存儲方式。
配置步驟簡單如下：
1、拷貝mysql的驅動包到路徑下即可
2、重命名activemq.xml文件爲activemq-bak.xml,同時複製一份activemq-jdbc.xml文件，並且重新命名爲：
activemq.xml。
3、修改activemq.xml內容。有效配置如下。
<persistenceAdapter>
<jdbcPersistenceAdapter dataSource="#mysql-ds"/>
</persistenceAdapter>
<bean id="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
<property name="url" value="jdbc:mysql://localhost/activemq?relaxAutoCommit=true"/>
<property name="username" value="root"/>
<property name="password" value="mxr"/>
<property name="maxActive" value="200"/>
<property name="poolPreparedStatements" value="true"/>
</bean>
原來有一段默認的derby的，註釋掉就可以了。注意這個文件裏面不能有中文（我嘗試加了中文註釋，結果很不幸的報錯了），否則會報錯（Invalid byte 1 of 1-byte UTF-8 sequence）。
好吧，爲了保持清爽，最後的配置文件如下：
<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd"><bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<value>file:${activemq.base}/conf/credentials.properties</value>
</property>
</bean><broker useJmx="false" brokerName="jdbcBroker" xmlns="http://activemq.apache.org/schema/core">
<persistenceAdapter>
<jdbcPersistenceAdapter dataSource="#mysql-ds"/>
</persistenceAdapter><transportConnectors>
<transportConnector name="default" uri="tcp://0.0.0.0:61616"/>
</transportConnectors>
</broker>
<bean id="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
<property name="url" value="jdbc:mysql://localhost/activemq?relaxAutoCommit=true"/>
<property name="username" value="root"/>
<property name="password" value="pwd"/>
<property name="maxActive" value="200"/>
<property name="poolPreparedStatements" value="true"/>
</bean>
</beans>
如果你不願意複製，那麼，去這裏下載吧。http://vdisk.weibo.com/s/3aAWe
好吧，如果你保證一切都配置ok了。那麼接下來創建數據庫吧。
create database activemq;
執行如上腳本即可。
執行完畢後，可以開始運行mq的實例了。
啓動mq
如下圖，啓動成功。
然後執行測試程序，測試程序此處下載http://vdisk.weibo.com/s/3aBwl
這次，我們先執行producer，然後再執行consumer，
在執行producer的時候。沒有被消費的消息會被持久化到數據庫中的哦，所以如果我們先執行consumer的話，這樣消息就不會被存到庫中了。
我們看到如上所示記錄。說明存儲消息成功了。
然後啓動consumer，當消息被處理後，就會從表中刪除了。
我們看看consumer的執行結果。當輸出最後一行記錄 100的時候，我們再去看看數據庫表。
此時數據庫表如下：
數據庫表是空的，ok。說明沒有任何問題。至此，activemq基於數據庫存儲消息的方式實現完成。
當然也可以配置，在處理後不刪除消息。
（十）——Activemq部署和鏈接
爲了交換信息（進行通信），生產者（producers）和消費者(consumers)（client）需要連接到broker。client到broker之間的通信是通過 transport connector完成的。activemq提供了一系列的協議用於client和-broker之間的信息交換。因爲mq用戶對於連接方式的需求是不同的，例如一些用戶希望高效，一些用戶希望安全。所以activemq視圖覆蓋用戶的所有使用場景。
上圖顯示了activemq的兩種網絡拓撲結構
duplex和forwardding
<networkConnectors>
<networkConnector name="default-nc" uri="multicast://default"/>
</networkConnectors>
forwarding模式：一個給定的broker在一個方向上僅僅接受消息，並且將消息傳送給另外一個brokers處理。
duplex是broker之間可以相互通信的。而forwarding只是單向的
另外講一個名詞吧：
Discovery，翻譯爲探索，發現。簡單到mq就是說檢測broker服務是否存在。client（consumer）通常想盡可能的發現所有可用的broker。對於broker，通常想找到網絡中其它可以建立連接的broker。
如果你要配置“network broker”，並且你知道網絡中每個broker的準確地址，，你可以以靜態的方式進行配置。你的client端可以用預先定義的URI連接到broker。這種情景大多數會在生產環境見到，當你想完全控制所有資源的時候。
但是在broker相互之間不知道對方確切地址的時候。必須使用另外一種動態位置的機制去發現可用的broker。這種機制多用於開發環境。因爲這種機制容易配置和以維護。
Static NetWorks:
static network connector 被用於創建一個網絡中多broker靜態的配置。這種協議使用多uril的形式。例子如下：
static:(uri1,uri2,..)?key=value
一下是這種方式配置的截圖和英文解釋：
PEER PROTOCOL：此協議用於嵌入的（embedded）的mq
（十一）——消息如何在MQ中進行存儲
JMS規範支持兩種類型的消息傳送：持久化和非持久化。一個帶有持久化屬性的消息在傳輸的時候必須被以日誌的方式進行可靠的存儲。對於一個非持久化的消息而言，JMS提供者必須盡最大努力去傳送消息。然而這些消息並不會被進行有效的存儲。
Activemq支持這兩種形式的消息傳送，同時也可以通過配置的方式支持消息的恢復。在兩者之間的狀態被緩存在了內存中。Activemq支持可插拔的消息存儲策略，提供了一下的可選存儲方式：存儲在內存中，春初在文件中，和關係型數據庫中。
持久化了的消息被用於一下兩種情況：1、當消息發送到broker之後，consumer一直可以獲取消息。2、當consumer沒有運行，而消息被髮送到了broker，在consumer啓動後還可以獲得消息。
一旦消息被consumer消費掉了。這個消息通常就會從broker的存儲中刪除。
Nonpersistent messages are typically used for sending notifications or real-time
data. You should use nonpersistent messages when performance is critical and guar-
anteed delivery of the message isn’t required.
對隊列（queue）消息存儲的存儲是直接的，消息存儲的方式是按照對列的先後順序來進行存儲的。即fifo(first in first out) 先進先出。
（十二）——基於KahaDB的消息存儲
KahaDB是activemq5.3版本以後推薦使用的存儲方式.KahaDB是一種基於文件系統和事物的存儲方式,它被設計和優化了消息的存儲.KahaDB方式存儲的宗旨就是儘可能的簡單易用和快速.基於文件的存儲方式意味着不需要第三方數據的依賴.這種方式的存儲使得activemq可以在很短的時間內被下載和正確的運行.
KahaDB消息存儲使用了一個事務日誌在它的索引上,它爲所有的目標使用一個唯一的索引文件.它可以用於有10000個活動鏈接的生產環境.每一個connection有一個獨立的隊列.可配置的KahaDB意味着它可以唄用戶大多數使用場景的調優.同大吞吐量的應用長促到大量消息的存儲場景.
在activemq中使用KahaDB,你需要進行如下的配置:
<broker brokerName="broker" persistent="true" useShutdownHook="false">
<persistenceAdapter>
<kahaDB directory="activemq-data" journalMaxFileLength="16mb"/>
</persistenceAdapter>
</broker>
KahaDB配置參數
