高可用方案对比：
activemq高可用方案 | Shared Database/ File system | Replicated LevelDB Store |
所需实例数 | 至少2个 | 至少6台实例（3台做zookeeper高可用集群） |
选举master机制 | 抢占数据库表/共享文件的排它锁 | 每台server注册到zookeeper，通过zookeeper选举出server编号最小的为master |
存储 | 数据库/共享文件 | leveldb |
保证消息不丢失机制 | 共享数据库/文件系统 | 数据同步（master同步到replicas/2个salves，剩余的slave通过异步的方式转发） |
优缺点 | 稳定性依赖数据库 性能依赖数据库 | 占用的资源多，1个zookeeper小集群至少3个实例，1个activemq小集群也至少得3个实例，6个实例的成本只为了保证1个activemq master实例的高可用，浪费资源 |
我搭建的zookeeper+leveldb+activemq集群：
activemq高可用工作原理：master收到消息且同步到slave后，才会发送确认消息到客户端，保证消息不丢失，master宕机后，zookeeper选举出server编号最小的成为新的master，保证了activemq集群高可用。
Zookeeper高可用工作原理：zookeeper集群同时只能一个leader对外提供服务，当leader宕机后，zookeeper默认采用投票数大于半数则胜出成为新的leader，继续为activemq提供服务
注：
Zookeeper高可用至少3台：因为zookeeper选举出leader默认是采用投票数大于半数则胜出成为leader的逻辑，如果只有2台的话，一台宕机，剩余一台无法选举出leader，整个zookeeper将无法对外提供服务
Activemq高可用至少3台实例：否则一台宕机，剩余一台的话zookeeper无法选出master，activemq集群无法工作
配置：
activemq.xml：
<replicatedLevelDB
directory="${activemq.data}/leveldb"
replicas="3"
bind="tcp://0.0.0.0:61621"
zkAddress="zookeeper1:2181,zookeeper2:2181,zookeeper3:2181"
hostname="IP1"
sync="local_disk"
zkPath="/activemq/leveldb-stores"/>3台activemq实例的brokeName要一致：
后台查看/启停activemq：
/opt/apache-activemq-5.14.3/bin: ./activemq status/restart/start/stop
zookeeper：通过环境变量的方式修改配置
/conf/zoo.cfg:
dataDir=/data
dataLogDir=/datalog
tickTime=2000
initLimit=5
syncLimit=2
autopurge.snapRetainCount=3
autopurge.purgeInterval=0
maxClientCnxns=60
standaloneEnabled=true
admin.enableServer=true
server.1=0.0.0.0:2888:3888;2181---3888是选举端口，2181是clientProt
server.2=zookeeper2:2888:3888;2181
server.3=zookeeper3:2888:3888;2181
修改每台的my_id分别为1,2,3
后台查看/启停zookeeper:
/apache-zookeeper-3.5.6-bin/bin: zkServer.sh status/start/stop/restart
