菡萏如佳人AMQ集群
Queue consumer clusters
ActiveMQ支持Consumer对消息高可靠性的负载平衡消费，如果一个Consumer死掉，该消息会转发到其它的Consumer消费的Queue上。
如果一个Consumer获得消息比其它Consumer快，那么他将获得更多的消息。
因此推荐ActiveMQ的Broker和Client使用failover：//transport的方式来配置链接。
Broker clusters
大部情况下是使用一系列的Broker和Client链接到一起。如果一个Broker死掉了，Client可以自动链接到其它Broker上。实现以上行为需要用failover协议作为Client。
如果启动了多个Broker，Client可以使用static discover或者 Dynamic discovery容易的从一个broker到另一个broker直接链接。
这样当一个broker上没有Consumer的话，那么它的消息不会被消费的，然而该broker会通过存储和转发的策略来把该消息发到其它broker上。
特别注意：ActiveMQ默认的两个broker，static链接后是单方向的，broker-A可以访问消费broker-B的消息，如果要支持双向通信，需要在netWorkConnector配置的时候，设置duplex=true 就可以了。
消息会较为平均的分配给2个集群，而不是每个消费者。即使某个消费者集群的消费者比其他集群中多，它获得的消息总数仍然差不多。不适合机器性能不均等的架构。
原因：networkConnector配置的可用属性conduitSubscriptions ：默认true，标示是否把同一个broker的多个consumer当做一个来处理
负载均衡的时候一般设置为false, 设置为false后，会按照消费者个数来分配。
Master Slave
在5.9的版本里面，废除了Pure Master Slave的方式，目前支持：
1：Shared File System Master Slave：基于共享储存的Master-Slave：多个broker实例使用一个存储文件，谁拿到文件锁就是master，其他处于待启动状态，如果master挂掉了，某个抢到文件锁的slave变成master
2：JDBC Master Slave：基于JDBC的Master-Slave：使用同一个数据库，拿到LOCK表的写锁的broker成为master
3：Replicated LevelDB Store：基于ZooKeeper复制LevelDB存储的Master-Slave机制，这个是5.9新加的
具体的可以到官方察看： http://activemq.apache.org/masterslave.html
JDBC Master Slave的方式
利用数据库作为数据源，采用Master/Slave模式，其中在启动的时候Master首先获
得独有锁，其它Slaves Broker则等待获取独有锁。
推荐客户端使用Failover来链接Brokers。
具体如下图所示：
Master失败
如果Master失败，则它释放独有锁，其他Slaver则获取独有锁，其它Slaver立即获得独有锁后此时它将变成Master，并且启动所有的传输链接。同时，Client将停止链接之
前的Master和将会轮询链接到其他可以利用的Broker即新Master。如上中图所示
Master重启
任何时候去启动新的Broker，即作为新的Slave来加入集群，如上右图所示
JDBC Master Slave的配置
使用