1.集群
集群:将相同的程序功能部署到两台或多台服务器上，这些服务器对外提供的功能都是一样的
2.为什么需要集群?
解决单点故障
提高系统服务能力
3.ActiveMQ主从集群方式-3种
1>shared filesystem Master-Slave 方式主从集群 --基于文件共享
文件系统共享方式主从集群:
通过共享存储目录(data/kahadb)来实现master和slave的主从信息备份
所有ActiveMQ的broker都在不断的获取共享目录的控制权，哪个broker抢到了就成为master,它将锁定该目录，锁定之后，其他的只能是slave；
当master主出现故障后，剩下的slave从将再进行争夺共享目录的控制权，谁抢到了共享目录的控制权，谁就成为主；
由于他们是基于共享目录的，所以当主出现故障后，其上没有被消费的消息在接下来产生的新的master主中可以继续进行消费；
环境搭建:
a.安装3个activeMQ
b.配置每个activeMQ的activemq.xml共享目录和端口 (搭建到多台就不需要更改)
<persistenceAdapter>
<kahaDB directory="${activemq.data}/kahadb"/>-->此处更改为同一个目录就是共享目录，例如更改为/opt/kahadb
</persistenceAdapter>
更改端口:
<transportConnectors>
<!-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB -->
<transportConnector name="openwire" uri="tcp://0.0.0.0:61616?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
<transportConnector name="amqp" uri="amqp://0.0.0.0:5672?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
<transportConnector name="stomp" uri="stomp://0.0.0.0:61613?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
<transportConnector name="mqtt" uri="mqtt://0.0.0.0:1883?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
<transportConnector name="ws" uri="ws://0.0.0.0:61614?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
</transportConnectors>
c.修改jetty.xml文件的端口
jettyPort
bean id="jettyPort" class="org.apache.activemq.web.WebConsolePort" init-method="start">
<!-- the default port number for the web console -->
<property name="host" value="0.0.0.0"/>
<property name="port" value="8161"/>
</bean>
主从区别:
web控制台，能访问的是主机器，不能访问的是从机器
localhost:8161 分别访问3个地址
测试java项目中访问:配置broker_url= failover:(tcp://localhost:61616，tcp://localhost:port2,tcp://localhost:port3)地址之间使用逗号分割然后测试:发现项目启动的时候只连接主机器
2>shared database Master-Slave 方式主从集群 --基于数据库共享
同1>的区别就是1>共享的file,现在共享database
a.activemq.xml文件中配置数据源:(配置在<broker>的外面，同时需要加入mysql的驱动包和数据库连接池Druid包，放入ActiveMQ的lib目录下)
b.共享目录的地方指定jdbc持久化
<persistenceAdapter>
<kahaDB directory="${activemq.data}/kahadb"/>-->此处更改为<jdbcPersistenceAdapter dataSource="#mysql-ds"/> 同上述bean的id
</persistenceAdapter>
c.程序连接使用同上方式，端口修改原则同上
3>Replicated levelDB Store 方式集群
5.9之后新增的特性，它使用zk从一组broker中协调选择一个broker作为master,其他broker转入slave模式: zk选举决定的
所有slave从节点通过复制master主节点的消息来实现消息同步，当主出现故障，没有被消费的消息在从服务器上也同步了一份，所以不会有信息的丢失(因为没有共享目录)
levelDB是Google开发的一套用于持久化数据的高性能类库，
Master的所有存储操作都将被复制到slaves；
在这个模式中，需要有半数以上的broker是正常的，集群才是可用的，超过半数broker故障，zk的选举算法将不能选择master,从而导致集群不可用
本质上此种模式activeMQ的个数不能太多，否则复制有太多的复制开销；
a.更改端口，同上述一致
b.ActiveMQ的集群配置:
activemq.xml文件中:
<persistenceAdapter>
<replicatedLevelDB
directory="${activemq.data}/leveldb" replicas="3" bind="tcp://0.0.0.0:0" zkAddress="192.168.0.101:2181" zkPassword="" hostname="ymklinux" sync="local_disk" />
</persistenceAdapter>
replicas 集群中存在的节点的数目
bind:哪个节点是主，就指定该节点的端口，进行数据复制的，0.0.0.0代表任意的ip，0代表任意算口
c.验证测试:
启动zookeeper
启动3个ActiveMQ
zk算法不支持超过半数ActiveMQ宕机