官方主从实现的文档：http://activemq.apache.org/masterslave.html
一、activeMQ主要的几类部署方式比较
1、默认的单机部署（kahadb）
activeMQ的默认存储的单机方式，以本地kahadb文件的方式存储，所以性能指标完全依赖本地磁盘IO，不能提供高可用。
2、基于zookeeper的主从（levelDBMaster/Slave）
5.9.0新推出的主从实现，基于zookeeper来选举出一个master，其他节点自动作为slave实时同步消息。
因为有实时同步数据的slave的存在，master不用担心数据丢失，所以leveldb会优先采用内存存储消息，异步同步到磁盘。所以该方式的activeMQ读写性能都最好，特别是写性能能够媲美非持久化消息。
优点：
实现高可用和数据安全
性能较好
缺点：
因为选举机制要超过半数，所以最少需要3台节点，才能实现高可用。
3、基于共享数据库的主从（Shared JDBC Master/Slave）
可以基于postgres、mysql、oracle等常用数据库。
每个节点启动都会争抢数据库锁，从而保证master的唯一性，其他节点作为备份，一直等待数据库锁的释放。
因为所有消息读写，其实都是数据库操作，activeMQ节点本身压力很小，性能完全取决于数据库性能。
优点：
实现高可用和数据安全
简单灵活，2台节点就可以实现高可用
缺点：
稳定性依赖数据库
性能依赖数据库
二、性能测试：
用同一台测试机作为master。测试代码为java，使用activemq-client-5.11.1提供的client，每个线程用一个连接反复写/读，所有线程完毕后，汇总测试结果。
每秒写/读吞吐量测试结果如下（测试机性能较差，测试结果仅仅用来做3种部署方式的横向比较）：
三、灾备方案（两种方式都已经测试通过）
1、leveldb方式
需要3台节点，2台在主机房，1台在备机房，主机房的节点权重设的比备机房节点高。
当master节点故障：
因为权重的关系，主机房另一个节点会自动被选举为新的master。
当主机房故障：
需要启动备用机房时，先更改备机房节点配置，把集群规模从3改成1，这样1个节点可以临时提供服务（此时不再保证高可用）。
2、共享数据库方式
3台节点即可，2台在主机房，1台在备机房，备机房节点指向灾备activeMQ数据库，平时要关闭。
当master节点故障：
主机房的另一个节点会自动取得数据库锁，成为新的master。
当主机房故障：
需要启动备用机房时，先完成activeMQ数据库的切换，然后启动灾备activeMQ节点即可临时外提供服务（此时不再保证高可用）。
