activeMQ实践（四）--大型系统的最佳实现之集群

activemq的集群实现主流目前有两种方式，master/slave和Broker Cluster。
master/slave的实现方式是通过持久化的排它锁，可以实现高可用（即一台服务器故障，会启用另一台服务器），但不能负载均衡。

一旦node A出现故障，就会释放锁让node B来继续提供服务.
而Broker Cluster是通过zookeeper来选举master服务器，但服务器挂掉之后由于没有持久化会导致消息的丢失，可负载均衡但不高可用。

那有没有一种方式即高可用有负载均衡呢？当然是有的，在这里只列出其中一种：

这样A和B接收的消息都可以被负载消费，A又通过B持久化消息，B和C又组成主从节点实现高可用。
下面我们使用一台服务器的不同端口来实现上面的集群配置：

首先将解压的activemq文件复制三份放在同一个文件夹下，再建立一个共享文件夹，再建立一个共享文件db：

第二步：修改配置apache-activemq-A下conf文件夹下的activemq.xml文件，主要是端口号和连接器，A提供服务的端口号是61616，不用换了，就配置连接器，并将其它不用的协议注释掉。
修改activemq.xml代码：

        <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>        <!--添加我们的连接器，我们已知其它具体的bc服务器，就静态发现比较方便-->        <networkConnectors>             <networkConnector name = "local_network" uri ="static:(tcp://127.0.0.1:61617,tcp://127.0.0.1:61618)"/>        </networkConnectors>

并且同时修改提供后端服务控制台jetty.xml的配置，此处A默认8161，所以不用修改
第三步：
同样修改node B服务器的activemq.xml文件，除了添加网络连接器和修改transportConnector端口之外，还需要配置持久化适配器：

        <persistenceAdapter>            <kahaDB directory="F:/activemq/activemq-jq/db"/>        </persistenceAdapter>

然后修改jetty.xml的后台端口：

    <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="8162"/>    </bean>

同样将node C也配置成B这样
第四步：然后顺序启动A,B,C三个服务器，会发现C虽然启动但命令行窗口会提示is locaked by another server，就是现在C节点不对外提供服务，只有B节点出现问题了释放锁了C节点才开始对外提供服务
然后用我们之前的第二次实践写的代码进行测试；
需要将AppProducer这个生产者的url去向修改一下，表示当一个连接失败自动跳到另一个连接：

    private static final String BROKER_URL = "failover:(tcp://127.0.0.1:61617,tcp://127.0.0.1:61618)?randomize=true";

这里A是一个broker集群就不作为生产者生产消息；
同样修改AppConsumer的url去向，A,B,C都作为消费者：

    private static final String BROKER_URL = "failover(tcp://127.0.0.1:61616,tcp://127.0.0.1:61617,tcp://127.0.0.1:61618)?randomize=true";

第五步：我们启动生产者发送消息，在A（localhost：8161）的控制台看不到这100条消息，而在B（localhost：8162）的控制台可以看到，C控制台是打不开的：

如果我们此时关掉B服务器，就可以打开C控制台看到这100消息。

第六步：启动消费者，发现信息被A消费了：
A网络连接状态

C网络连接状态

到此为此这个小集群的演示就完成了，我们还可以尝试增加一个服务器来扩展看看架构又是怎么样的！