【ActiveMQ 主从集群】的三种方式和优点

柔情只为你懂 2022-03-11 10:52 526阅读 0赞

# **ActiveMQ 有哪些优点和用处：** #

1.  Dubbo框架中 消费者调用生产者服务，生产者返回结果给消费者。这个过程就是同步处理。点对点模式 就是 异步处理，两个操作在两个进程中，互不影响干涉。
2.  **MQ 技术可以 流量消峰 。**

假如有500w请求同时请求服务器，时间也很短，这就是多线程高并发的情况，然后我们在 服务器的前面添加一个 MQ，这500w个请求，每个请求过来都给mq发送一个消息，然后 这个消息就保存在了 MQ 中，因为我们使用的是点对点模式，是异步处理，所以 我们的服务器会自己主动到mq中获取 信息，获取到信息就等于获取到了请求，这样就减少了服务器的压力。-----------高并发环境才使用mq队列技术。

1.  **系统解耦合。**系统A和系统B通过 MQ中介 来进行连接，这样子项目A和项目B没有任何的耦合，都是独立的项目。项目b down机了，项目a没有影响，任然可以正常工作。

如果项目A和项目B直接连接，那么项目B down机了，项目A也不能正常工作了。

# **【ActiveMQ主从集群模式】：** #

\---------为什么需要集群？

1.  集群可以【解决单点故障】问题。
2.  集群可以【提高系统的可用性】。
3.  集群可以【提高系统的服务能力】。

因为【集群】 是 通过 横向增加【服务器】来提高性能的，所以 服务器也多，处理能力就越强，服务能力就越强，而且当发生故障的时候，一台服务器停机了，但是还有其他的服务器可以提供服务，所以可用性很高，解决了单点故障的发生。

## **【ActiveMQ 主从集群】的三种方式：** ##

### **1、shared filesystem Master-Slave方式主从集群****：** ###

1.原理：通过共享存储目录（kahaDB）来实现master和slave的主从信息同步；

因为我们的 ActiveMQ 默认是将消息进行持久化的，所以默认情况下ActiveMQ接收到了消息之后，=会将消息存储到 data目录下kahadb目录下。假如我们的ActiveMQ集群中配置了【 三台 ActiveMQ服务器】，而且这三台ActiveMQ服务器都在同一个【linux系统】中，所以我们就可以设置这三台ActiveMQ 服务器 同时 【共享 同一个 ActiveMQ 持久化消息的目录】。这样配置之后，当这三个ActiveMQ中有一个 服务器 停机了， 其他两个ActiveMQ 还是可以提供服务，而且依然可以从 共享的目录中 获取信息。

2.在集群当中，所有的 ActiveMQ 服务器都可以 不断的获取 共享目录的控制权，当前我们配置了三个ActiveMQ 服务器，这三个服务器 是【互相抢夺】共享目录的控制权，那个ActiveMQ服务器抢到了共享目录的控制权，这个ActiveMQ服务器就是主，那么其余的服务器都是从了。 而且只有我们的主服务器可以真正的操作 共享目录。

3.需要注意的是：只能有一个主，其余的都是从，而且只有主可以操作共享目录，当主停机了之后，那么剩余的从会争夺共享目录的 控制权，谁抢到了控制权谁就又称为主，然后这个新的主会接着上一个主的执行位置继续执行，而且我们ActiveMQ 只会去连接主服务器，也就是读写都是操作我们的主，所以 从 其实就是主的备用。

**保留地址的写法：当不知道 安装到那台机器上，我们就采取保留ip地址，这样子我们的ip地址就活了，就不是死的了：不能写死，写死了就不能更换机器了。**

**0.0.0.0是保留地址，代表任意ip地址。**

**0.0.0.0:0** **也是保留地址，代表任意ip地址，任意端口。**

**配置好三个ActiveMQ 服务器集群之后：**然后开启三个ActiveMQ服务器，然后我们的这三个服务器就开始抢夺 对 共享目录 的 控制权，如果 其中的 一个ActiveMQ服务器抢夺到了 对共享目录的 控制权，就会在控制台中 提示下面这段话：

**\[ActiveMQ Task-1\] INFO org.apache.activemq.transport.failover.FailoverTransport -** **Successfully connected to tcp://192.168.242.128:61617 这个提示连接上了那台主服务器中了。**

当前主服务器是61617，然后我们手动将这个服务器关闭，关闭之后会报出：java.io.EOFException这个异常，然后过了没多长时间，这段时间内我们的服务器正在抢夺共享目录的控制权，当有一台抢夺到了之后，我们的控制台打印信息的操作就重新继续执行了，当前主机器变成了61618，这种故障转移 是 自动完成的，我们不用写任何的代码，当 主 服务器 停掉了，那么其他的从机器就会抢夺 控制权，谁抢到了谁就成为了 主机器。

**上面 三个ActiveMQ服务器 是安装在同一个Linux中的 ，所以可以共享同一个linux中的目录，当这三个ActiveMQ服务器安装台 不同的 三个 独立的 linux中，那么怎么实现 目录的共享呢？**

这样情况 我们就 需要【开启第四个Linux】，然后将第四个Linux中的磁盘，通过【linux命令】分别挂载到【另外三个linux上】，这样我们安装了ActiveMQ服务器的三台linux就可以访问第四台没有安装ActiveMQ服务器的linux的磁盘了，这样子 这三个ActiveMQ的消息都存放在这个【第四个linux的磁盘中】。这样子又实现了目录的共享。

### **2. shared database Master-Slave方式主从集群** **：**  ###

这种方式和第一种方式是差不多的，因为这种方式是 共享数据库的方式，第一种是共享目录的方式，其中的原理是一样的。

1.  共享数据库的方式和共享目录的方式是一样的，都是能有一个主，其余的都是从，数据库只能被 当前的主 来进行操作，ActiveMQ只连接当前的主，读写操作都是主的，数据库控制权也是主的，当主停机了，那么从就开始抢夺数据库的控制权了。
2.  配置步骤看 第七阶段xmind讲义。

**注意：** 因为我们是【共享数据库】，所以我们需要给 三个ActiveMQ服务器，提供一个存放消息的数据库，我们只需要 给这三个 ActiveMQ创建一个数据库就可以了，不用给他们创建表，因为表示ActiveMQ运行是自己创建的，所以说我们只需要提供数据库，不需要创建表。

1.  当我们是 【发布订阅模式】的时候，我们开启生产者时候，查看数据库后，里面是没有存放数据的，不是没有存放进去，而是因为 生产者将产生的信息传递给ActiveMQ之后，我们的ActiveMQ当前推送消息的模式为【发布订阅】模式，所以采用的 是 推模式（广播模式），直接就将接收到的消息 推送给我们的消费者了，不管我们消费者此时有没有在监听，我们的ActiveMQ只会推送一次，也就是广播一次，不会推第二次，所以说 广播一次之后，就将数据库中的信息删除了，所以我们看不到 【发布订阅模式】下信息存放在数据库中。
2.  当我们是【点对点模式】的时候，会将信息存放在数据库中，如果消费者不获取就一次存放在数据库中，放消费者获取了，这条信息就从数据库中删除。

### **3、Replicated LevelDB Store方式集群****：** ###

1.  这中集群方式 不需要和上面两种方法一样 需要配置一下【共享目录】或者是【共享数据库】，因为 zookeeper自动帮我们将 主 机器中 【存放消息目录】 中的数据 同步到了 所有的从机器【存放消息的目录】中了，也就是在这种方式下集群，主从机器的 存放消息的目录是自动同步的。
2.  这种集群方式中 三个AxctiveMQ获取 共享目录或共享数据库 控制权的 方式变了，上面两种方法获取控制权的方式 为 三个ActiveMQ自己互相抢夺，但是在我们这种方式集群下，获取控制权是由 我们的zookeeper注册中心 进行分配 。 怎么分配呢？ 就是我们zookeeper的投票机制，集群中所有的能够工作的 activemq超过半数以上zookeeper才能正常工作，如果正常运行的activemq小于半数，那么我们的zookeeper就不能正常工作了，当zookeeper正常工作，当主机器down机了，那么我们zookeeper就开始投票了，所有的正常运行的activemq开始投票，谁的票数最多，谁就当主机器。

（3）我们这种集群方式，正常运行的机器必须超过半数以上，我们的zookeeper才能帮助我们故障转移。如果小于半数就不能进行 投票选举，就不能选出新的主机器，就不能故障转移。

**这种情况下就一台 zookeeper，所以这台zookeeper可能会出现单点故障，所以我们需要给 zookeeper进行集群设置：**

1.  集群中zookeeper的数量为 【奇数个】，因为根据我们zookeeper运行机制，我们可以推导出：

3台zookeeper 和 4台 zookeeper 所 带来的效果是一样的。 所以我们不如使用3台zookeeper，因为少一台zookeeper，节省了资源，为什么4台和3台效果是一样的呢？

我们的 zookeeper的运行机制是：当【集成】中 所有可以 正常运行的zookeeper加起来是半数以上，我们的zookeeper 才能正常的运行，才能在一台主的zookeeper停掉之后，然后开始 选取投票算法，如果正常的运行的机器小于半数，zookeeper不能正常运行，更不用说 帮我们故障转移了。

3 台 zookeeper，主的 坏了，剩下两台： 2 > 3/2=1.5 故障转移，正常运行

主的又坏了，剩下一台，1 < 1.5 不能正常运行了。

4 台 zookeeper ，主的坏了，剩下3台， 3 > 4 / 2 = 2 故障转移，正常运行

主的又坏了，剩下2台，2 == 2 没有在半数一样，所以说 不能正常运行了。

从上面可以看出 3台和4台数量的zookeeper所带来的效果一样的。 我们不如配置3台，还能省一台的资源。