ActiveMQ集群整体认识

前言

最终需要掌握 Replicated LevelDB Store部署方式，这种部署方式是基于ZooKeeper的。

集群分为两种方式：
1.伪集群：集群节点都搭在一台机器上
2.真集群：集群节点分布在多台机器上
更多详细： 真集群与伪集群的区别

一、为什么使用集群？

1. 实现高可用，以排除单点故障引起的服务中断。
2. 实现负载均衡，以提升效率为更多的客户提供服务。

二、ActiveMQ集群部署方式

ActiveMQ集群的部署方式主要有下面2种：

1. Broker Clusters 模式：实现负载均衡，多个broker之间同步消息，已达到服务器负载的可能。
2. Master Slave 模式：实现高可用，当主服务器宕机时，备用服务器可以立即补充，以保证服务的继续。

1. 失效转移连接

该策略用于控制消费者的访问，这是我们在编写代码的时候要使用的连接方式。一个消费者连接到多个broker集群的中的一个broker，当该broker出问题时，消费者自动连接到其他一个正常的broker。消费者使用 failover 协议来连接broker，通常叫做 失效转移（也叫故障转移，断线重连机制，FailOver）策略，语法如下：
failover:(uri1,uri2,...,uriN)?transportOptions

1.uri:消息服务器的地址 
2.transportOptions参数说明： 
        randomize：默认为 true ，表示在URI列表中选择URL连接时是否采用随机策略。 
        initialReconnectDelay：默认为10，单位为毫秒，表示一次尝试重连之间等待的时间。 
        maxReconnectDelay：默认 30000，单位毫秒，最长重连的时间间隔。

例如：

failover:(tcp://localhost:61616,tcp://localhost:61617)?randomize=false

2. Broker Clusters 部署

Broker-Cluster的部署方式就可以解决负载均衡的问题。Broker-Cluster部署方式中，各个broker通过网络互相连接，并共享queue，保证消息同步。

各个broker进行消息同步使用的是NetworkConnection (网络连接器)，主要用于配置各个broker之间的网络通讯方式，用于服务器传递信息。 分为静态连接器和动态连接器。

1. 静态连接器

2. 动态连接器

静态连接器过于局限，动态连接器可随意扩展服务器连接。

3. Master Slave 部署（主从）

只需要掌握 Replicated LevelDB Store。

该 Master Slave主从方案所实现的 高可用架构具体内容可参考： ActiveMQ与HA架构(master/slave)

通过部署多个broker实例，选举产生一个master和多个slave，master宕机后由slave接管服务来达到高可用性。Master-Slave的方式虽然能解决多服务热备的高可用问题，但无法解决负载均衡和分布式的问题。Broker Cluster的部署方式刚好可以解决负载均衡的问题。一般两者结合使用。
这里主要介绍2种配置方案（一般只使用）：

1. Share storage master slave(共享存储)
   包括：Shared File System Master slave 和 JDBC Store Master Slave 两种模式
   此模式中Master和Slave的数据是共享的（相当于共享同一个数据库），当master失效后，slave会自动接管服务，无需手动进行数据的copy与同步，因为master存储数据之后，这些数据在任何时候对slave都是可见的。
   master与slave之间，通过共享文件的“排他锁”或者分布式排他锁(ZooKeeper)来决定Broker的状态与角色，获取锁权限的Broker作为master，其它的Broker则作为slave。如果master失效，它必将失去锁权限，那么其它的slave将通过锁竞争来选举新master，没有获取锁权限的Broker作为slave，并等待锁的释放(间歇性尝试获取锁)。

   • Shared File System Master Slave模式（只适合单台主机部署，不适合多台主机部署）

     这种方式是最常用的模式，架构简单，可靠实用。我们只需要一个SAN文件系统即可。使用文件系统来共享数据文件，多个Broker共享同一个文件系统。配置如下：
     ```
     
       
               
     
     ```

   • JDBC Store Master Slave模式（适合多台主机部署）

     数据存储用的是数据库（MySQL/Oracle等），相对于日志文件而言，JDBC Store通常认为是低效的。配置如下：
     ```
       
           
               
                     
       
      
       
           
           
           
           
           
       
     ```
     
     

2. Replicated LevelDB Store（使用ZooKeeper协调多个Broker）重要
   基于复制的LevelDB Store模式是ActiveMQ 5.9以后新增的特性，这是ActiveMQ全力打造的HA存储引擎。 一般都使用这种方式。由于利用zk 进行配置管理，可以方便监控，同时配置也相对简单。

   使用ZooKeeper（集群）注册所有的ActiveMQ Broker。只有其中的一个Broker可以对外提供服务（也就是Master节点），其他的Broker处于待机状态，被视为Slave。如果Master因故障而不能提供服务，则利用ZooKeeper的内部选举机制会从Slave中选举出一个Broker充当Master节点，继续对外提供服务。

   由于基于ZooKeeper（通常ZooKeeper集群至少需要3个实例，才能保证ZooKeeper本身的高可用性），所以Broker最低需要3个。activemq.xml中配置如下：

三、 Master Slave和Broker Cluster结合使用（常用方式）

---	高可用	负载均衡
Master Slave	是	否
Broker Cluster	否	是

Master Slave只能实现高可用性，不能实现负载均衡。
Broker Cluster 只能实现负载均衡，不能实现高可用性。
Master Slave和Broker Cluster 结合使用可以实现高可用和负载均衡，如下图：
按 A->B->C 顺序启动节点服务。

这个集群是综合了Broker Cluster和master/slave两种基本集群方式，其中master/slave（B和C）是基于共享存储实现的。A和B组成消息同步，A和C组成消息同步是为实现均衡负载，B和C组成master/slave是为了实现高可用。

1. 如果A宕机，集群退化成标准master/slave集群，只是了失去负载均衡能力。
2. 如果B宕机，C会继续提供服务，集群退化成Broker Cluster集群，失去高可用能力。
3. 如果C宕机也会失去高可用能力（同B）。

ABC无论哪一台宕机，集群都不会崩溃，但是需要迅速恢复。