ActiveMQ的集群方案对比及部署

青旅半醒 2022-06-10 01:59 311阅读 0赞

**ActiveMQ技术学习 [https://www.itkc8.com][https_www.itkc8.com]**

内嵌代理所引发的问题：

*  消息过载
 *  管理混乱

如何解决这些问题——集群的两种方式：

*  Master slave 
 *  Broker clusters

ActiveMQ的集群有两种方式：

*  MASTER/SLAVE模式
 *  Cluster模式

## Pure Master Slave ##

##      ##

![outside_default.png][]

Pure master slave的工作方式：

当master broker失效的时候。Slave broker 做出了两种不同的相应方式

*  启动network connectors和transport connectors
 *  slave broker停止，slave broker只是复制了master broker的状态

在任何情况下我们都应该先尝试连接master，故在客户端我们这样配置：

1.  failover://(tcp://masterhost:61616,tcp://slavehost:61616)?randomize=false

Pure Master Slave具有以下限制：

*  只能有一个slave broker连接到master broker。 
 *  在因master broker失效后slave才接管（保证消息完全拷贝）
 *  要想恢复master，停止slave，拷贝slave中的数据文件到master中，然后重启；
 *  Master broker不需要特殊的配置。Slave broker需要进行以下配置：

1.  <broker masterConnectorURI="tcp://masterhost:62001" shutdownOnMasterFailure="false">   
2.  ...   
3.  <transportConnectors>   
4.  <transportConnector uri="tcp://slavehost:61616"/>   
5.  </transportConnectors>   
6.  </broker>

## Shared File System Master Slave ##

如果你使用共享文件系统，那么你可以使用Shared File System Master Slave。如下图所示：

![outside_default.png][]

客户端使用failover Transport 去连接 broker，例如：

1.  failover:(tcp://broker1:61616,tcp://broker2:6161 7，broker3:61618）

1.  <broker useJmx="false" xmlns="http://activemq.org/config/1.0">   
2.  <persistenceAdapter>   
3.  <journaledJDBC dataDirectory="/sharedFileSystem/broker"/>   
4.  </persistenceAdapter>   
5.  …   
6.  </broker>

其中/sharedFileSystem是文件共享的系统文件目录

## JDBC Master Slave ##

JDBC Master Slave的工作原理跟Shared File System Master Slave类似，只是采用了[数据库][Link 1]作为持久化存储  
  
![outside_default.png][]

客户端调用：

1.  failover:(tcp://broker1:61616,tcp://broker2:616167,broker3:61618）

1.  <beans>   
2.  <broker xmlns="http://activemq.org/config/1.0" brokerName="JdbcMasterBroker">   
3.  <persistenceAdapter>   
4.  <jdbcPersistenceAdapter dataSource="\#mysql-ds"/>   
5.  </persistenceAdapter>   
6.  </broker>   
7.  <bean id="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">   
8.  <property name="driverClassName" value="com.mysql.jdbc.Driver"/>   
9.  <property name="url" value="jdbc:mysql://localhost:3306/test?relaxAutoCommit=true"/>   
10. <property name="username" value="username"/>   
11. <property name="password" value="passward"/>   
12. <property name="poolPreparedStatements" value="true"/>   
13. </bean>   
14. </beans>

## Broker clusters-静态 ##

Broker clusters ，网络型中介（network of brokers）  
  
  
连接到网络代理的两种方式：

*  静态的方法配置访问特定的网络代理
 *  发现中介（agents）动态的探测代理

**静态网络代理**

Static:(uri1,uri2,uri3,…)?key=value 或是Failover:(uri1, … , uriN)?key=value

下面给出一个配置实例：

1.  <networkConnectors>  
2.  <networkConnector name=”local network”  
3.            uri=”static://(tcp://remotehost1:61616,tcp://remotehost2:61616)”/>  
4.  </networkConnectors>

## 几种集群对比 ##

*  broker的集群在多个broker之前fail-over和 load-balance，master-slave能fail-over，但是不能load- balance
 *  消息在多个broker之间转发，但是消息只存储在一个broker上，一旦失效必须重启，而主从方式master失效，slave实时备份消息。
 *  jdbc方式成本高，效率低
 *  master-slave方式中pure方式管理起来麻烦

因此，我们把MASTER/SLAVE和BROKER CLUSTER两者相结合，可以得到一个完全解决方案：即又可以做到集群又可以做到任何一个BROKER如果发生宕机节点消息也不丢失。

# Master/Slave集群搭建-传统式 #

一般activemq的Master Slave是基于KAHADB的阻塞来做的，先看一下原理

![outside_default.png][]

注意红色加粗的地方，这是传统的Master Slave的一个缺陷。这样做太不安全了！

下面给出核心配置：  
master配置（不要忘了改conf目录下的jetty.xml文件中的端口）

1.  <transportConnectors>  
2.              **  **
3.              <transportConnector name="openwire" uri="tcp://0.0.0.0:61616?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>  
4.              <transportConnector name="amqp" uri="amqp://0.0.0.0:5672?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>  
5.              <transportConnector name="stomp" uri="stomp://0.0.0.0:61613?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>  
6.              <transportConnector name="mqtt" uri="mqtt://0.0.0.0:1883?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>  
7.              <transportConnector name="ws" uri="ws://0.0.0.0:61614?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>  
8.  </transportConnectors>

1.  <persistenceAdapter>  
2.    
3.             <kahaDB directory="/localhost/kahadb"/>  
4.  </persistenceAdapter>

slave配置（不要忘了改conf目录下的jetty.xml文件中的端口）

1.  <transportConnectors>  
2.              **  **
3.              <transportConnector name="openwire" uri="tcp://0.0.0.0:61617?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>  
4.              <transportConnector name="amqp" uri="amqp://0.0.0.0:5682?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>  
5.              <transportConnector name="stomp" uri="stomp://0.0.0.0:61623?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>  
6.              <transportConnector name="mqtt" uri="mqtt://0.0.0.0:1903?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>  
7.              <transportConnector name="ws" uri="ws://0.0.0.0:61634?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>  
8.  </transportConnectors>

1.  <persistenceAdapter>  
2.    
3.             <kahaDB directory="/localhost/kahadb"/>  
4.  </persistenceAdapter>

*  把master conf 目录中的jetty.xml中的端口改成8161
 *  把slave conf 目录中的jetty.xml中的端口改成8162

此时把master和slave先后启动，其实你也可以不用管顺序，谁先启动谁会先把

<kahaDB directory=“/localhost/kahadb”/>  
  
中的db lock住，它就成了mater，而此时另一个实例会处于“pending”状态。  
  
当master宕机后slave会自动启动转变为master。  
当宕掉的master再次被启动后然后变成slave挂载在原先的slave下面变成slave’  
客户端的访问代码如下，只要改[spring][]中的配置，代码层无需发动：

1.  <bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">  
2.          <property name="brokerURL" value="failover:(tcp://192.168.0.101:61616,tcp://192.168.0.101:61617)"   
3.          <property name="useAsyncSend" value="true" />  
4.          <property name="alwaysSessionAsync" value="true" />  
5.          <property name="useDedicatedTaskRunner" value="false" />  
6.  </bean>

# Master/Slave集群搭建-基于ZooKeeper #

搭个集群，还要共享磁盘？？？见了鬼去了，这种方案肯定不是最好的！  
  
  
因此，从ActiveMQ5.10开始出现了使用ZooKeeper来进行Master/Slave搭建的模式。  
  
  
搭建时请务必注意下面几个问题：

*  参于master slave组网的配置中<broker xmlns=“http://activemq.apache.org/schema/core” brokerName=“zk\_cluster\_nodes“必须一至。
 *  ActiveMQ至少需要3个实例（2N+1公式），只要不符合2N+1，master slave集群会发生集群崩溃

##    Master/Slave集群搭建-基于ZooKeeper搭建 ##

搭建ZooKeeper，你可以搭建3个ZooKeeper实例也可以只用1个，如果出于高可用性考虑建议使用3台ZooKeeper。  
  
  
下载ZK，我们在这边使用的是“zookeeper-3.4.6”，把它解压到[Linux][]服务器上，在其conf目录下生成zoo1.cfg文件 ，内容如下：

1.  tickTime=2000  
2.  initLimit=10  
3.  syncLimit=5  
4.  dataDir=/opt/zk/data/1  
5.  clientPort=2181  
6.  \#server.1=127.0.0.1:2887:3887  
7.  \#server.2=127.0.0.1:2888:3888  
8.  \#server.3=127.0.0.1:2889:3889

在ZK的data目录下建立一个目录，名为“1”，并在其下建立一个文件，文件名为“myid”并使其内容为1

![outside_default.png][]

如果你需要在本地搭建2N+1的ZooKeeper，那你必须依次在data目录下建立2、3两个文件夹并且在每个文件夹下都有一个myid的文件，文件的内容依次也为2，3，然后把下面注释掉的3行server.1 server.2 server.3前的\#注释符放开。  
因此data目录下的目录名和myid中的内容对应的就是server.x这个名字。

1.  tickTime=2000  
2.  initLimit=10  
3.  syncLimit=5  
4.  dataDir=/opt/zk/data/1  
5.  clientPort=2181  
6.  server.1=127.0.0.1:2887:3887  
7.  server.2=127.0.0.1:2888:3888  
8.  server.3=127.0.0.1:2889:3889

按照2N+1，你必须至少建立3个ActiveMQ实例。在搭建前我们先来看一下我们的集群规划吧

![outside_default.png][]

本例中，我们只使用一个ZK节点，即2181端口来做MQ1-3的数据文件共享。

核心配置  
以下是传统的Master/Slave配置

1.  <persistenceAdapter>  
2.    
3.             <kahaDB directory="/localhost/kahadb"/>  
4.  </persistenceAdapter>

基于ZK的配置

1.  <persistenceAdapter>    
2.        <replicatedLevelDB     
3.                directory="$\{activemq.data\}/leveldb"    
4.                replicas="3"    
5.                bind="tcp://0.0.0.0:0"    
6.                zkAddress="192.168.0.101:2181"    
7.                zkPassword=""    
8.                hostname="ymklinux"  
9.                sync="local\_disk"    
10.               />    
11. </persistenceAdapter>

不要忘了，3个MQ实例的brokerName必须一致，要不然你会在集群启动时出现：  
**Not enough cluster members when using LevelDB replication**  
这样的错误。  
  
  
或者在集群启动后当master宕机slave被promote成master时发生集群崩溃。

依次把3台mq实例均配置成replicatedLevelDB即可，在此配置中有一个zkPath，笔者使用的是默认配置。你也可以自行加上如：

1.  <persistenceAdapter>    
2.       <replicatedLevelDB     
3.               directory="$\{activemq.data\}/leveldb"    
4.               replicas="3"    
5.               bind="tcp://0.0.0.0:0"    
6.               zkAddress="192.168.0.101:2181"    
7.               zkPassword=""    
8.               hostname="ymklinux"  
9.               sync="local\_disk"  
10.              zkPath="/activemq/leveldb-stores"   
11.              />    
12. lt;/persistenceAdapter>

网上所有教程都没有说明这个zkPath到底是一个什么东西，害得一堆的使用者以为这是一个目录，以为用ZK做mq的集群也需要“共享”一块磁盘空间。  
  
  
这个zkPath代表zookeeper内的“路径”，即你运行在2181端口的zk内的“寻址节点”，类似于JNDI。如果你没有这个zkPath，默认它在zk内的寻址节点为“/default”。加入到某一组master slave中的mq的实例中的zkPath必须完全匹配。  
  
  
这边还有一个replicas=“3”的设置 ，这边的数字指的就是ActiveMQ实例的节点数，它需要满足2N+1，因此你也可以5台（1拖4）。

master slave一旦启动后，在客户端的配置就很简单了，如下：

1.  <bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">  
2.      <property name=“brokerURL” value=“failover:(tcp://192.168.0.101:61616,tcp://192.168.0.101:61617, tcp://192.168.0.101:61618)" />  
3.       <property name="useAsyncSend" value="true" />  
4.       <property name="alwaysSessionAsync" value="true" />  
5.       <property name="useDedicatedTaskRunner" value="false" />  
6.  </bean>

你可以如此实验：

*  生产和消费分成两个程序。
 *  生产发一条消息，注意看console会输出如“\[INFO\] Successfully reconnected to tcp://192.168.0.101:61616”
 *  手工停止61616这台实例，然后你会发觉61617或者 是61618中有一台被promoted to master
 *  然后运行consumer，consumer会连上被promoted的实例并继续消费刚才那3条消息

是为。。。high available。

![outside_default.png][]

# Master/Slave集群搭建-Broker Cluster搭建 #

所谓cluster即负载匀衡，它负载的是“用户”的请求，此处的用户就是调用端

![outside_default.png][]

cluster的用法就是用来分散用户的“并发”请求的。前面説过，ActiveMQ的Cluster有两种：

1.  动态式(multicast）
2.  静态式（static）

在实际应用场景中”静态方式“被大量使用，动态式使用的是multicast即组播式，基本已经被淘汰，因此我们主要基于静态方式来做cluster讲解。

## Master/Slave集群搭建-Broker Cluster搭建方式 ##

核心配置

1.  <networkConnectors>   
2.       <networkConnector uri="static:(tcp://ymklinux:61617)" duplex=“false"/>    
3.  </networkConnectors>

请维持各cluste节点间不同的持久化方式（你也可以使用kahadb，但不要做成和master slave一样的排它锁方式啊。

**在61616中的配置**

1.  <networkConnectors>   
2.       <networkConnector uri="static:(tcp://ymklinux:61617)" duplex=“false"/>    
3.  </networkConnectors>

**在61617中的配置**

1.  <networkConnectors>   
2.       <networkConnector uri="static:(tcp://ymklinux:61616)" duplex=“false"/>    
3.  </networkConnectors>

**客户端的配置**

1.  <bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">  
2.      <property name=“brokerURL” value=“failover:(tcp://192.168.0.101:61616,tcp://192.168.0.101:61617)" />  
3.       <property name="useAsyncSend" value="true" />  
4.       <property name="alwaysSessionAsync" value="true" />  
5.       <property name="useDedicatedTaskRunner" value="false" />  
6.  </bean>

# Master/Slave集群搭建-Broker Cluster和Master Slave对比 #

优点

*  自动分发调用端请求
 *  流量分散

缺点

当调用端连接上任意一个节点发送了一条消息，比如说往NODE A发送了一条消息。

此时消费端还没来得及消费NODE A上的消息该节点就发生宕机了。此时调用端因为有failover所以它会自动连上另一个节点（NODE B）而该节点上是不存在刚才“发送的消息”的，因为刚才发送到NODE A的消息只在NODE A上，没有同步到NODE B上。  
  
  
因为只有Master Slave会做主从间的消息同步，这是一个致命伤。  
  
**具体实验步骤：**

1.  send一条消息到cluster，并观察send时连接的是哪个节点
2.  直接把该节点进程杀掉
3.  用消费端连上集群
4.  观察消费端是否拿得到消息

![outside_default.png][]

# 鱼与熊掌兼得法-完美解决方案 #

我们知道：

*  master/slave模式下，消息会被逐个复制
 *  而cluster模式下，请求会被自动派发

那么可不可以把两者集成起来呢？答案是有的，网上所谓的独创。。。统统是错的！！对，因为我全试验过了我敢这么説，写得都是些个啥呀。。。一个个还COPY不走样，全错了而且。  
  
  
我这个才叫独创，来看原理。

![outside_default.png][]

## MASTER SLAVE+BROKER CLUSTER的搭建 ##

*  我们使用ZK搭建MASTER SLAVE
 *  我们使用BROKER CLUSTER把两个“组”合并在一起

先来看下面的集群规划

![outside_default.png][]

### MASTER SLAVE+BROKER CLUSTER的搭建-Group1的配置 ###

由于这涉及到两个组6个ActiveMQ的实例配置，如果把6个配置全写出来是完全没有必要的，因此我就把配置分成两组来写吧。每个组的配置对于其组内各个节点都为一致的，除去那些个端口号。Group1的配置（保持6个实例中brokerName全部为一致）

1.  <networkConnectors>   
2.       <networkConnector uri="static:(tcp://ymklinux:61619,tcp://ymklinux:61620,tcp://ymklinux:61621)" duplex=“false"/>    
3.   </networkConnectors>

可以看到这边的broker cluster的配置是用来确保每一台都可以和Group2中的各个节点保持同步

1.  <persistenceAdapter>    
2.      <replicatedLevelDB     
3.                            directory="$\{activemq.data\}/leveldb"    
4.                            replicas="3"    
5.                            bind="tcp://0.0.0.0:0"    
6.                            zkAddress="192.168.0.101:2181"    
7.                            zkPassword=""    
8.                            hostname="ymklinux"  
9.                            sync="local\_disk"  
10.               zkPath="/activemq/leveldb-stores/group1"   
11.                 />    
12. </persistenceAdapter>

### MASTER SLAVE+BROKER CLUSTER的搭建-Group2的配置 ###

1.  <networkConnectors>   
2.      <networkConnector uri="static:(tcp://ymklinux:61616,tcp://ymklinux:61617,tcp://ymklinux:61618)" duplex=“false"/>    
3.  </networkConnectors>

可以看到这边的broker cluster的配置是用来确保每一台都可以和Group1中的各个节点保持同步

1.  <persistenceAdapter>    
2.      <replicatedLevelDB     
3.                            directory="$\{activemq.data\}/leveldb"    
4.                            replicas="3"    
5.                            bind="tcp://0.0.0.0:0"    
6.                            zkAddress="192.168.0.101:2182"    
7.                            zkPassword=""    
8.                            hostname="ymklinux"  
9.                            sync="local\_disk"  
10.               zkPath="/activemq/leveldb-stores/group2"   
11.                 />    
12. </persistenceAdapter>

### MASTER SLAVE+BROKER CLUSTER的搭建-客户端 ###

客户端：

1.  <property name="brokerURL" value="failover:(tcp://192.168.0.101:61616,  
2.                                        tcp://192.168.0.101:61617,  
3.                                        tcp://192.168.0.101:61618,  
4.                                        tcp://192.168.0.101:61619,  
5.                                        tcp://192.168.0.101:61620,  
6.                                        tcp://192.168.0.101:61621)" />

把6台实例全部启动起来（乖乖，好家伙）  
把客户端写上全部6台实例（乖乖，好长一陀）

![outside_default.png][]

### MASTER SLAVE+BROKER CLUSTER的搭建-实验 ###

*  使用生产端任意发送3条消息。

*  生产端连上了61616，发送了3条消息，然后我们把61616所属的activemq1的进程直接杀了

*  然后运行消费端，消费端连上了61618，消费成功3条消息

搞定了！  
  
  
**哈 哈 ，不要急，再重复一遍该实验，来：**

*  先把所有实例进程全部杀掉
 *  把6台实例全部启动起来（乖乖，好家伙）
 *  把客户端写上全部6台实例（乖乖，好长一陀）
 *  使用生产端任意发送3条消息。
 *  生产端连上了61616，发送了3条消息，然后我们把61616所属的activemq1的进程直接杀了
 *  然后运行消费端，消费端连上了61620，控台显示无任何消息消费

哈 哈 ，死惨了。。。作者滚粗。。。  
  
  
**为什么 ？WHY？**

## 所谓的完美方案并不是真正的完美方案-情况A ##

是的，以上的方案存在着这一漏洞！来看原理！

![outside_default.png][]

对于上述情况，当61616宕机后，如果此时请求被failover到了group1中任意一个节点时，此时消费端完全可以拿到因为宕机而未被消费掉的消费。

##  ##

## 所谓的完美方案并不是真正的完美方案-情况B ##

![outside_default.png][]

对于上述情况，当61616宕机后，如果此时请求被failover到了group2中任意一个节点时，此时因为group2中并未保存group1中的任何消息，因此只要你的请求被转发到另一个group中，消费端是决无可能去消费本不存在的消息的。这不是有可能而是一定会发生的情况。因为在生产环境中，请求是会被自由随机的派发给不同的节点的。  
![outside_default.png][]  
  
**我为什么要提这个缺点、要否认之前的篇章？ 我就是为了让大家感受一下网上COPY复制还是错误信息的博文的严重性**，那。。。怎么做是真正完美的方案呢。。。

# 如何让方案完美 #

![outside_default.png][]

我们来看，如果我们把两个group间可以打通，是不是就可以在上述情况发生时做到failover到group2上时也能消费掉group1中的消息了呢？  
  
  
怎么做？很简单，其实就是一个参数

![outside_default.png][]

## duplex=true ##

什么叫duplex=true？  
  
  
它就是用于mq节点间双向传输用的一个功能，看下面的例子

![outside_default.png][]

这就是duplex的使用方法，我很奇怪，竟然这么多人COPY 那错的1-2篇博文，但是就是没有提这个duplex的值，而且都设的是false。  
  
duplex的作用就是mq节点1收到消息后会变成一个sender把消息发给节点2。  
  
此时客户如果连的是节点2，也可以消息节点1中的消息，因此我给它起了一个比英译中更有现实意义的名称我管它叫“穿透”。  
  
下面来看用“穿透机制”改造的真正完美方案吧。

# 最终完美解决方案 #

考虑到消费端可能会发生：  
  
  
当Group1中有未消费的数据时时，消费端此时被转派到了Group2中的任意一个节点。  
  
  
因此，在配置时需要进行如下的穿透：

![outside_default.png][]

按照这个思路我们在各Group中的各节点中作如下配置即可：

**Group1中的配置**

1.  <networkConnectors>   
2.      <networkConnector uri="static:(tcp://ymklinux:61619,tcp://ymklinux:61620,tcp://ymklinux:61621)" duplex="true"/>    
3.  </networkConnectors>

**Group2中的配置**

Group2中的每一个节点都不再需要来一句以下这样的东西了：

1.  <networkConnectors>   
2.      <networkConnector uri="static:(tcp://ymklinux:61616,tcp://ymklinux:61617,tcp://ymklinux:61618)" duplex="true"/>    
3.   </networkConnectors>

因为，你设的是duplex=true，它相当于下面几行的效果：

1.  **    **
2.  <networkConnector name="group1-broker1" uri="static:(tcp://broker1:61619)" duplex="false" />    
3.      
4.  **    **
5.  <networkConnector name="group1-broker2" uri="static:(tcp://broker0:61620)" duplex="false" />    
6.    
7.  **    **
8.  <networkConnector name="group1-broker3" uri="static:(tcp://broker0:61621)" duplex="false" />   
9.    
10.   
11. **    **
12. <networkConnector name="group2-broker1" uri="static:(tcp://broker1:61616)" duplex="false" />    
13.     
14. **    **
15. <networkConnector name="group2-broker2" uri="static:(tcp://broker0:61617)" duplex="false" />    
16.   
17. **    **
18. <networkConnector name="group2-broker3" uri="static:(tcp://broker0:61618)" duplex="false" />

现在知道为什么要duplex=true了吧！

## 验证 ##

1.  先把所有实例进程全部杀掉
2.  把6台实例全部启动起来（乖乖，好家伙）
3.  把客户端写上全部6台实例（乖乖，好长一陀）
4.  使用生产端任意发送3条消息。
5.  生产端连上了61619（属于Group2)，发送了3条消息，然后我们把61619所属的activemq4的进程直接杀了
6.  然后运行消费端，消费端连上了61616，控台显示消费成功3条消息

**大功告成！！！**

# 结束语 #

从生产环境的高可用性来説，如果需要使用完美解决方案的话我们至少需要以下这些实体机  
  
  
**2台实体机**

*  每台虚出3个子节点来（用VM），供3个MQ实例运行使用，2\*3共为6个
 *  并且一台实体机必须承载一个GROUP，同一个GROUP最好不要跨实体机或虚拟

**2台实体机**

*  每台虚出3个子节点来（用VM），供3个ZK 节点使用，2\*3共为6个
 *  并且一台实体机必须承载一个ZK GROUP，同一个ZK GROUP最好不要跨实体机或虚拟

**同一台实体机上不得又安装ZK又安装MQ**  
  
  
上述是ActiveMQ Master Slave + Broker Cluster的最小化配置，为了得到更高的高可用性，建议6个MQ实例间全部需要有物理机承载。  
  
  
但是，上述情况是用于应对**百万级并发**消息的生产环境而言才需要如此大动干戈，对于常规环境笔者建议：  
  
  
搞两台高配置的VM分散在两台不同的实体机，做MASTER SLAVE即可，当然笔者强烈建议使用ZK做ActiveMQ的Master Slave，ZK可以用3个节点，分别来自3个不同的虚机（不是指在一个VM里启3个不同端口的ZK实例，而是来自于3台虚机），至于3台虚机是否在不同实体机上，这倒不是太大要求，因为在MASTER SLAVE中的ZK只作节点信息、消息同步使用，不会受太多并发访问之苦。  
  
  
还有一种集群方式留给大家自己去练习，很简单，就是几个节点间无MASTER SLAVE也只做static Broker Cluster， 用的就是这个“穿透原理”。  
  
**ActiveMQ技术学习 [https://www.itkc8.com][https_www.itkc8.com]**  
比如说，我有5个节点，其中生产连着A和B，消费连着C、D、E，然后在A上对C、D、E做穿透，B也对C、D、E做穿透，客户端只对A和B做failover，这就构成了一个spoker机制。它也可以制作出一个MASTER SLAVE + Broker Cluster的模型来，然后producer对a,b进行监听，而consumer failerover至c,d,e即可，这个架构不难，动一下手就会了。

[https_www.itkc8.com]: https://www.itkc8.com
[outside_default.png]: /images/20220610/734bbfdd7ae147ec9e0b709df810ef52.png
[Link 1]: http://lib.csdn.net/base/mysql
[spring]: http://lib.csdn.net/base/javaee
[Linux]: http://lib.csdn.net/base/linux