ActiveMQ的高可用性实现

朱雀 2021-05-12 11:55 505阅读 0赞

一，ActiveMQ高可用性的架构

ActiveMQ的高可用性架构是基于Master/Slave 模型的。ActiveMQ总共提供了四种配置方案来配置HA，其中Shared Nothing Master/Slave 在5.8版本之后不再使用了，并在ActiveMQ5.9版本中引入了基于Zookeeper的[Replicated LevelDB Store HA方案。][Replicated LevelDB Store HA]

二，Master/Slave架构的配置解释：

**1、Shared Nothing Master/Slave  （非共享存储方案）** 该架构最大的特点是：

1）Master 和 Slave各自都单独存储持久化的消息，它们不共享数据。

2）Master收到持久化消息时，需要先同步(sync)给Slave之后，才向Producer发送ACK确认。

3）只有Master负责Client的请求，Slave不接收Client请求。Slave连接到Master，负责备份消息。

4）Master出现故障，Slave有两种处理方式：❶自己成为Master；❷关闭（停服务）---根据具体配置而定。

5）Master 与 Slave之间可能会出现“Split Brain”现象。比如：Master本身是正常的，但是Master与Slave之间的网络出现故障，网络故障导致Slave认为Master已经宕机，因为它自己会成为Master(根据配置：shutdownOnMasterFailure)。此时，对Client而言，就会存在两个Master。

6）Slave 只能同步它连接到Master之后的消息。在Slave连接到Master之前Producer向Master发送的消息将不会同步给Slave，这可以通过配置（waitForSlave）参数，只有当Slave也启动之后，Master才开始初始化TransportConnector接受Client的请求(Producer的请求)

7）如果Master 或者 Slave其中之一宕机，它们之间不同步的消息 无法 自动进行同步，此时只能手动恢复不同步的消息了。也就是说：“ActiveMQ没有提供任何有效的手段，能够让master与slave在故障恢复期间，自动进行数据同步”

8）对于非持久化消息，并不会同步给Slave。因此，Master宕机，非持久化消息会丢失。

![20180102110126822][]

关于ShareNothing 高可用配置的一点理解：

A、由上面的第2)步可知：Producer向Master发消息之后，Master需要将消息同步给Slave之后，才向Producer返回确认ACK。因此，对Producer的响应有一定的延时。

如果为了保证快速响应，即Producer给Master发消息之后，Master收到了消息立即给Producer回复，然后再在后台把消息同步给Slave。这又会造成数据不一致性问题。

因为，如果Master收到了消息立即给Producer回复之后，Master还未来得及向Slave同步就宕机了，如果此条消息还在Master内存中，则Master宕机后消息就丢失了。如果Master收到Producer的消息，先写入磁盘，然后再向Producer返回确认ACK，然后再在后台与Slave同步，那么Master就需要标记每条消息是否已经成功同步到了Slave，若消息还未同步到Slave，则Master重启恢复后，需要立即同步Slave。只有当Slave成功同步了所有的Master上的消息之后，才能上线。这也无法实现 automatic failover。

关于一个很好的高可靠性解决方案：可参考[ Hadoop HA中的QJM机制][Hadoop HA_QJM]。其核心就是：1）采用集群，能容忍不超过大多数机器的失效；2）数据只写大多数机器就返回确认，保证Client快速的响应能力；3）数据在后台在异步同步到集群所有的机器，从而保证高可用。

B、这里的Master--Slave机制中，只有一台Slave，并不是Slave集群(见上面结构图)。Master宕机，或者Slave宕机后，都会给整个服务造成极大的风险，并没有像Hadoop HA中的那样能够容忍“不超过大多数机器失效”的保证，即没有做到真正的高可用性。

C、还可能出现“双主”问题。即上面提到的“Split Brian”现象。

**2、Shared Database Master/Slave**

这是很常用的一种架构。“共享存储”，意味着Master与Slave之间的数据是共享的。

那如何避免冲突呢？通过争夺数据库表的排他锁，只有Master有锁，未获得锁的自动成为Slave。

![20180102110136403][]

对于“共享存储”而言，只会“共享”持久化消息。对于非持久化消息，它们是在内存中保存的。可以通过配置（forcePersistencyModeBrokerPlugin persistenceFlag）属性强制所有的消息都持久化。

当Master宕机后，Slave可自动接管服务成为Master。由于数据是共享的，因此Master和Slave之间不需要进行数据的复制与同步。Slave之间通过竞争锁来决定谁是Master。

**3、Shared File system Master/Slave**

这种方式和共享数据库存储原理基本一样，（文件系统也有文件锁），故不详细介绍。

二、最近的 [Replicated LevelDB Store][Replicated LevelDB Store HA]

这种方式使用Zookeeper选举Master。要进行选举，则需要多数派的“参与者”。因为Replicated LevelDB Store中有多个Broker，从多个Broker中选举出一个成为Master，其他的则成为Slave。只有Master接收Client的连接，Slave负责连接到Master，并 接收（ 同步方式、异步方式）Master上的数据。

以上也表明：每个Broker都是 单独存储数据的 。因为Master要把新的数据复制到Slave上。从这个角度看：称这种方式为“Share Storage”有点不合适。

1、[Quorum机制][Hadoop HA_QJM]的又一应用

假设有3个Broker，那么选举时至少需要两个Broker同意（大多数）之后，才能选出Master。此外，只需要当新消息复制到大多数Broker上时，就可以给Producer返回ACK。其他少数Broker则可以在后台以异步方式复制新的消息。

比如说：一共有3个Broker，一个Master，二个Slave。当新消息到达Master时，Master需要将消息同步到其中一台Slave之后，才能向Producer发送ACK确认此次消息成功发送。

而剩下的另一台Slave，则可以在后台以异步方式复制这个新消息。此外，还能容忍一台Slave宕机。（能容忍不超过大多数的Broker宕机）

这种设计要求，可以保证集群中消息的可靠性，只有当(replicas/2 + 1)个节点物理故障，才会有丢失消息的风险。另外，也提高了一定的响应性，因为它不需要将消息同步到所有的Slave上，而只需要同步到大多数Broker上。

2、以何种标准判断谁是Master，谁是Slave呢？

【选举将会根据“消息日志的版本戳”、“权重"的大小决定，即“版本戳”越大(数据最新)、权重越高的broker优先成为master，其他broker作为slave并跟随master。】

参考：

http://www.cnblogs.com/hapjin/p/5663024.html

https://activemq.apache.org/artemis/docs/1.0.0/ha.html

http://shift-alt-ctrl.iteye.com/blog/2069250

http://activemq.apache.org/replicated-leveldb-store.html

[Replicated LevelDB Store HA]: http://activemq.apache.org/replicated-leveldb-store.html
[20180102110126822]: /images/20210511/bcfed5f3130f4ce8bd555a26fd898b13.png
[Hadoop HA_QJM]: http://www.cnblogs.com/hapjin/p/5626889.html
[20180102110136403]: /images/20210511/0e6d5da0c84f4da78dc57d9ae33f6f3b.png