ActiveMQ主备配置

ActiveMQ的主备有三种方式：纯Master/Slave、文件共享方式、数据库共享方式。
1、纯Master/Slave
这种方式的主备不需要对Master Broker做特殊的配置，只要在Slave Broker中指定他的Master就可以了，指定Master有两种方式，最简单的配置就是在broker节点中添加masterConnectorURI=”tcp://localhost:61616″即可，还有一种方式就是添加一个services节点，可以指定连接的用户名和密码，配置如下：

Java

<masterConnectorremoteURI="tcp://localhost:61616"userName="system"password="manager"/>

</services>

纯Master/Slave只允许一个Slave连接到Master上面，也就是说只能有2台MQ做集群，同时当Master挂了之后需要停止Slave来恢复负载。
2、数据库共享方式
这种方式的主备采用数据库做消息的持久化，支持多个Slave，所有broker持久化数据源配置成同一个数据源，当一个broker获取的数据库锁之后，其他的broker都成为slave并且等待获取锁，当master挂了之后，其中的一个slave将会立刻获得数据库锁成为master，重启之前挂掉的master之后，这个master也就成了slave，不需要停止slave来恢复。由于采用的是数据库做为持久化，它的性能是有限的。
3、文件共享方式
这种方式的主备具有和数据库共享方式的负载一样的特性，不同的是broker的持久化采用的是文件（我这里用KahaDB），slave等待获取的锁是文件锁，它具有更高的性能，但是需要文件共享系统的支持。
Window下共享KahaDB持久化的目录，配置如下：

Java

<kahaDBdirectory="//172.16.1.202/mqdata/kahadb"/>

</persistenceAdapter>

Linux下需要开启NFS服务，具体操作如下：
创建共享目录(192.168.0.1)：
1、修改etc/exports，添加需要共享的目录：/opt/mq/data *(rw,no_root_squash)
2、启动NFS服务 service nfs start/restart
3、查看共享 showmount –e
4、 NFS服务自启动 chkconfig –level 35 nfs on

挂载共享目录(192.168.0.2)：
1、挂载：mount –t nfs 192.168.0.1:/opt/mq/data /opt/mq/data
2、启动自动挂载：在etc/fstab文件添加10.175.40.244:/opt/mq/data /opt/mq/data nfs defaults 0 0
然后指定KahaDB的持久化目录为/opt/mq/data即可。

AIX系统的文件共享和Linux类似，也是启动NFS服务。
注意：如果Master服务器宕机了，Slave是不会获得文件锁而启动，直到Master服务器重启。
Window下Master上有Slave连接时如图：
ActiveMQ主备配置
客户端连接的brokerURL为failover:(tcp://localhost:61616,tcp://localhost:61617)。用第三部分的代码测试，先向Master Broker发送一个消息，然后关闭master，运行获取消息的方法，即可获取之前发送的消息。

////////////////////////////////////////////////////////////////////////////////////////////////////

Queue consumer clusters ：

简介： ActiveMQ 支持订阅同一个 queue 的 consumers 上的集群。如果一个 consumer 失效，那么所有未被确认（ unacknowledged ）的消息都会被发送到这个 queue 上其它的 consumers 。如果某个 consumer 的处理速度比其它 consumers 更快，那么这个 consumer 就会消费更多的消息。

主要是解决 consumers 间的负载平衡。

配置：不需要特殊配置（个人理解）

Broker clusters/ Networks of brokers

简介：一个常见的场景是有多个 JMS broker ，有一个客户连接到其中一个 broker 。如果这个 broker 失效，那么客户会自动重新连接到其它的 broker 。在 ActiveMQ 中使用 failover:// 协议来实现这个功能。如果某个网络上有多个 brokers 而且客户使用静态发现（使用 Static Transport 或 Failover Transport ）或动态发现（使用 Discovery Transport ），那么客户可以容易地在某个 broker 失效的情况下切换到其它的 brokers 。当有多个 broker 时，如果某个 broker 上没有 consumers ，那么这个 broker 上的消息可能会因得不到处理而积压起来。目前的解决方案是使用 Network of brokers ，以便在 broker 之间存储转发消息。

存储转发机制：

ActiveMQ主备配置

配置：

备注：使用两个 broker ，分则负责不同的队列和主题

Broker1 ：

<networkConnector uri="static:(tcp://localhost:61621)"

name="bridge"

dynamicOnly="false"

conduitSubscriptions="true"

decreaseNetworkConsumerPriority="false">

</dynamicallyIncludedDestinations>

</staticallyIncludedDestinations>

</excludedDestinations>

</networkConnector>

</networkConnectors>

</persistenceAdapter>

</transportConnectors>

</broker>

Broker2 ：

< networkConnectors>

<networkConnector uri="static:(tcp://localhost:61620)"

name="bridge"

dynamicOnly="false"

conduitSubscriptions="true"

decreaseNetworkConsumerPriority="false">

</dynamicallyIncludedDestinations>

</excludedDestinations>

</staticallyIncludedDestinations>

</networkConnector>

</networkConnectors>

</persistenceAdapter>

</transportConnectors>

</broker>

Jndi ：

java.naming.provider.url=tcp://192.168.1.20:61620

主要是解决负载平衡和高可用性问题。

Master Slave

简介：在一个网络内运行多个 brokers 或者 stand alone brokers 时存在一个问题，这就是消息在物理上只被一个 broker 持有，因此当某个 broker 失效，那么你只能等待直到它重启后，这个 broker 上的消息才能够被继续发送（如果没有设置持久化，那么在这种情况下，消息将会丢失）。 Master Slave 背后的想法是，消息被复制到 slave broker ，因此即使 master broker 遇到了像硬件故障之类的错误，你也可以立即切换到 slave broker 而不丢失任何消息。主要分为三类： Pure Master Slave / Shared File System Master Slave / JDBC Master Slave

Pure Master Slave ：一个 master 只对应一个 slave

ActiveMQ主备配置