JMS-ActiveMQ学习-6 主从集群

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&amp;wireFormat.maxFrameSize=104857600"/>
<transportConnector name="amqp" uri="amqp://0.0.0.0:5672?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
<transportConnector name="stomp" uri="stomp://0.0.0.0:61613?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
<transportConnector name="mqtt" uri="mqtt://0.0.0.0:1883?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
<transportConnector name="ws" uri="ws://0.0.0.0:61614?maximumConnections=1000&amp;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宕机