Active-MQ in Action 读书笔记

转自：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配置参数