ActiveMQ的持久化与集群

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。