当一个应用被部署于生产环境，灾备计划是非常重要的，以便从网络故障，硬件故障，软件故障或者电源故障中恢复。通过合理的配置ActiveMQ，可以解决上诉问题。最典型的配置方法是运行多个Broker，一旦某台机器或者某个broker失效，其他broker能够顶上去。这种方式叫做Master/Slave，一个broker作为Master提供服务，而其他broker则作为slave等待master失效从而顶上。 目前activemq提供2种master/slave配置方式：

* Sharing nothing

broker拥有自己唯一的消息存储

* Sharing storage

broker之间共享一个消息存储设备，比如关系数据库，共享文件系统等。但是一个时间段内只能有一个broker占据他们。

1. 不共享式Master/Slave
     该模式下，Master与Slave拥有各自独立的消息存储设备。他是最简单的提供高可用性的消息Broker。Slave需要额外的配置，而Master不需要。
     所有的消息命令如消息、反馈、订阅、事务等会被从master复制到slave，如图所示，她发生在master收到这些消息之前。

     slave启动后会连接到master，所以master要先启动起来。slave只有在master失效后才会建立通信连接以顶替master。
     客户端给master发送消息后，master会首先将他转发到slave，等待slave反馈存储完毕后，master才开始处理这个消息。
     当master失效后，slave有2个选择
     关闭slave
          管理员重新配置这个slave作为master，然后再配置一个slave作为替补，并将之前存储的消息数据复制一份给slave，以同步。
     开启通信端口并初始化网络连接
          slave自动升级为master

缺点：
          master只会把slave连接后的消息传给他，而连接master之前的消息，不会被复制过去。不过你可以通过配置waitForSlave属性来让master一直等待slave启动才开始工作。
          master只允许一个slave，而slave不能再有slave

何时使用：
          当master失效后，可接受服务器维护时间，以及管理手工部署新的master和slave

2. 共享存储式Master/Slave
     不共享式的Master Slave让各个broker保持了相对独立性，而共享式则是让所有broker共享同一个存储器，这个存储器一定时间内只能被一个broker占有。相比非共享式，优点是一旦master失效，无需手工恢复，而且也不限制slave broker数量。
     共享式目前分为2种，共享数据库和共享文件系统。    值得一提的是，另外新的一种是基于zookeeper的，将会在5.9版中发布，详情查看 http://www.cnblogs.com/dycg/p/3177450.html
     
     基于数据库的共享
     原理是把消息命令都存储在数据库中，并且在数据库中加锁，一旦master失效后，slave获得该锁后继续服务。
          

只要你拥有数据库，并且不在意使用数据库而造成的性能相对其他方式有所降低的话，可以考虑。

基于共享文件系统的方式
     其实就是把数据库换成了一个共享文件系统如SAN等。