ActiveMQ的集群方式综述
ActiveMQ的集群方式主要由两种：Master-Slave和Broker Cluster
Master-Slave
Master-Slave方式中，只能是Master提供服务，Slave是实时地备份Master的数据，以保证消息的可靠性。当Master失效时，Slave会自动升级为Master，客户端会自动连接到Slave上工作。Master-Slave模式分为四类：Pure Master Slave、Shared File System Master Slave和JDBC Master Slave，以及Replicated LevelDB Store方式 。
Master-Slave方式都不支持负载均衡，但可以解决单点故障的问题，以保证消息服务的可靠性。
Broker Cluster
Broker Cluster主要是通过network of Brokers在多个ActiveMQ实例之间进行消息的路由。Broker Cluster模式支持负载均衡，可以提高消息的消费能力，但不能保证消息的可靠性。所以为了支持负载均衡，同时又保证消息的可靠性，我们往往会采用Msater-Slave+Broker Cluster的模式。
注意：
以下的测试均在一台机器上进行，为避免多个ActiveMQ****之间在启动时发生端口冲突，需要修改每个ActiveMQ****的配置文件中MQ****的服务端口。如果实际部署在不同的机器，端口的修改是不必要的。
Pure Master Slave方式
ActiveMQ5.8以前支持，自从Activemq5.8开始，Activemq的集群实现方式取消了传统的Pure Master Slave方式，并从Activemq5.9增加了基于zookeeper+leveldb的实现方式。
[图片上传失败...(image-9d56e8-1553515192235)]
使用两个ActiveMQ服务器，一个作为Master，Master不需要做特殊的配置；另一个作为Slave，配置activemq.xml文件，在
Shared File System Master Slave方式
就是利用共享文件系统做ActiveMQ集群，是基于ActiveMQ的默认数据库kahaDB完成的，kahaDB的底层是文件系统。这种方式的集群，Slave的个数没有限制，哪个ActiveMQ实例先获取共享文件的锁，那个实例就是Master，其它的ActiveMQ实例就是Slave，当当前的Master失效，其它的Slave就会去竞争共享文件锁，谁竞争到了谁就是Master。这种模式的好处就是当Master失效时不用手动去配置，只要有足够多的Slave。
如果各个ActiveMQ实例需要运行在不同的机器，就需要用到分布式文件系统了。
Shared JDBC Master Slave
JDBC Master Slave模式和Shared File Sysytem Master Slave模式的原理是一样的，只是把共享文件系统换成了共享数据库。我们只需在所有的ActiveMQ的主配置文件中activemq.xml添加数据源，所有的数据源都指向同一个数据库。
然后修改持久化适配器。这种方式的集群相对Shared File System Master Slave更加简单，更加容易地进行分布式部署，但是如果数据库失效，那么所有的ActiveMQ实例都将失效。
配置修改清单
1、开启网络监控功能（useJmx="true"）
2、数据库持久化配置，注释掉之前kahadb消息存储器
3、增加数据源mysql-ds
4、修改客户端上连接url为类似于failover:(tcp://0.0.0.0:61616,tcp://0.0.0.0:61617,tcp://0.0.0.0:61618)?randomize=false
注：默认情况下，failover机制从URI列表中随机选择出一个URI进行连接，这可以有效地控制客户端在多个broker上的负载均衡，但是，要使客户端首先连接到主节点，并在主节点不可用时只连接到辅助备份代理，需要设置randomize = false。
5、可以看到只有一台MQ成为Master，其余两台成为slave并会尝试成为Master，并不断重试。且两台slave的管理控制台将无法访问。
测试方法
先启动生产者，发送几条消息启动消费者，可看到接收到的消息关闭消费者生产者继续发送几条消息-消息A停止broker01（可看到生产者端显示连接到broker02（tcp://0.0.0.0:61617）了，同时运行broker02的Shell也显示其成为了Master）生产者继续发送几条消息-消息B启动消费者消费者接收了消息A和消息B，可见broker02接替了broker01的工作，而且储存了之前生产者经过broker01发送的消息关闭消费者生产者继续发送几条消息-消息C停止broker02（可看到生产者端显示连接到broker03（tcp://0.0.0.0:61618）了，同时运行broker03的Shell也显示其成为了Master）生产者继续发送几条消息-消息D启动消费者消费者接收了消息C和消息D，可见broker03接替了broker02的工作，而且储存了之前生产者经过broker02发送的消息再次启动broker01，生产者或消费者均未显示连接到broker01(tcp://0.0.0.0:61616)，表明broker01此时只是个Slave
Replicated LevelDB Store
ActiveMQ5.9以后才新增的特性，使用ZooKeeper协调选择一个node作为master。被选择的master broker node开启并接受客户端连接。 其他node转入slave模式，连接master并同步他们的存储状态。slave不接受客户端连接。所有的存储操作都将被复制到连接至Master的slaves。
如果master死了，得到了最新更新的slave被允许成为master。推荐运行至少3个replica nodes。
配置修改清单
1、 使用性能比较好的LevelDB替换掉默认的KahaDB
directory="${activemq.data}/leveldb" replicas="3" bind="tcp://0.0.0.0:62623" zkAddress="127.0.0.1:2181" hostname="localhost" zkPath="/activemq/leveldb-stores"/> 配置项说明： 2、修改客户端上连接url为failover:(tcp://0.0.0.0:61616,tcp://0.0.0.0:61617,tcp://0.0.0.0:61618)?randomize=false 3、可以看到只有一台MQ成为Master，其余两台成为slave。且两台slave的管理控制台将无法访问。 Leveldb是一个google实现的非常高效的kv数据库，目前的版本1.2能够支持billion级别的数据量了。 在这个数量级别下还有着非常高的性能，采用单进程的服务，性能非常之高，在一台4核Q6600的CPU机器上，每秒钟写数据超过40w，而随机读的性能每秒钟超过10w。由此可以看出，具有很高的随机写，顺序读/写性能，但是随机读的性能很一般，也就是说，LevelDB很适合应用在查询较少，而写很多的场景。LevelDB应用了LSM (Log Structured Merge) 策略，通过一种类似于归并排序的方式高效地将更新迁移到磁盘，降低索引插入开销。 限制：1、非关系型数据模型（NoSQL），不支持sql语句，也不支持索引；2、一次只允许一个进程访问一个特定的数据库；3、没有内置的C/S架构，但开发者可以使用LevelDB库自己封装一个server； 同Shared JDBC Master Slave 测试方法
LevelDB解释
测试方法