ActiveMQ存储消息可以采用多种持久化方案，每种方案都有自己特有的集群方案。
1. 文件型持久化方案
文件型持久化方案包含三种存储方式：AMQ Message store, KahaDB，LevelDB Store。
AMQ Message store是ActiveMQ 5默认的存储。
KahaDB是ActiveMQ5.4的默认存储，是AMQ Message store的继任者。
LevelDB Store是也是基于文件的持久化数据库。
这3种持久化存储方式由于都是基于文件的，ActiveMQ broker集群方式可以采用Shared File System Master Slave方式，就是将数据文件保存在共享的文件系统里。Broker master 和 Broker slave共享数据文件，master挂掉之后，slave可以直接接管master的工作。
2. 基于JDBC持久化方案
这种方案是将消息通过JDBC保存在数据库中，ActiveMQ的JDBC方案支持多种数据库，Apache Derby，Axion，DB2，HSQL，Informix，MaxDB，MySQL，Oracle，Postgresql，SQLServer，Sybase。
在JDBC持久化方案中，ActiveMQ broker集群方式可以采用JDBC Master Slave方式。Broker master和Broker slave使用相同的数据库，但在同一时刻，只有master可以操作数据库，当master挂掉之后，slave可以直接接管master的工作。
在上面描述的集群方案中，broker已经是master-slave集群了，但是共享的数据库并不是集群，仍然存在单点故障的风险。一般采用2中方式来去除单点：
- 采用支持集群的数据库，很多数据库都支持集群部署，比如mysql和oracle。
- 采用例如C-JDBC这样的数据库集群中间件，将数据复制到多个独立的数据库中来避免单点。
3. Replicated LevelDB Store
在第3种方案中，也用到了LevelDB，但是它和我们之前提到的基于文件的持久方案完全不同。
Replicated LevelDB Store采用zookeeper从一组broker中选出一个master，master接受客户端的连接，然后其他broker则是slave，他们连接到master，并且不接受客户端的连接。所有的持久化操作都会复制(replicated)到连接的slave。
所有的消息都会等待一个法定人数（quorum）个slave更新完成。法定人数(quorum）表示2n+1。类似zookeeper中法定人数的概念。所以理论上，这种方案的数据可靠性类似于zookeeper。
