消息中间件(四)-----activemq集群

构建ActiveMQ集群

ActiveMQ的集群方式综述

ActiveMQ的集群方式主要由两种：Master-Slave和Broker Cluster

Master-Slave

Master-Slave方式中，只能是Master提供服务，Slave是实时地备份Master的数据，以保证消息的可靠性。当Master失效时，Slave会自动升级为Master，客户端会自动连接到Slave上工作。Master-Slave模式分为四类：Pure Master Slave、Shared File System Master Slave和JDBC Master Slave，以及Replicated LevelDB Store方式 。

Master-Slave方式都不支持负载均衡，但可以解决单点故障的问题，以保证消息服务的可靠性。

Broker Cluster

Broker Cluster主要是通过network of Brokers在多个ActiveMQ实例之间进行消息的路由。Broker Cluster模式支持负载均衡，可以提高消息的消费能力，但不能保证消息的可靠性。所以为了支持负载均衡，同时又保证消息的可靠性，我们往往会采用Msater-Slave+Broker Cluster的模式。

注意：

以下的测试均在一台机器上进行，为避免多个ActiveMQ之间在启动时发生端口冲突，需要修改每个ActiveMQ的配置文件中MQ的服务端口。如果实际部署在不同的机器，端口的修改是不必要的。

Pure Master Slave方式

ActiveMQ5.8以前支持，自从Activemq5.8开始，Activemq的集群实现方式取消了传统的Pure Master Slave方式，并从Activemq5.9增加了基于zookeeper+leveldb的实现方式。

使用两个ActiveMQ服务器，一个作为Master，Master不需要做特殊的配置；另一个作为Slave，配置activemq.xml文件，在<broker>节点中添加连接到Master的URI和设置Master失效后不关闭Slave。具体配置参考页面：http://activemq.apache.org/pure-master-slave.html

Shared File System Master Slave方式

就是利用共享文件系统做ActiveMQ集群，是基于ActiveMQ的默认数据库kahaDB完成的，kahaDB的底层是文件系统。这种方式的集群，Slave的个数没有限制，哪个ActiveMQ实例先获取共享文件的锁，那个实例就是Master，其它的ActiveMQ实例就是Slave，当当前的Master失效，其它的Slave就会去竞争共享文件锁，谁竞争到了谁就是Master。这种模式的好处就是当Master失效时不用手动去配置，只要有足够多的Slave。

如果各个ActiveMQ实例需要运行在不同的机器，就需要用到分布式文件系统了。

Shared  JDBC Master Slave

JDBC Master Slave模式和Shared File Sysytem Master Slave模式的原理是一样的，只是把共享文件系统换成了共享数据库。我们只需在所有的ActiveMQ的主配置文件中activemq.xml添加数据源，所有的数据源都指向同一个数据库。

然后修改持久化适配器。这种方式的集群相对Shared File System Master Slave更加简单，更加容易地进行分布式部署，但是如果数据库失效，那么所有的ActiveMQ实例都将失效。

配置修改清单

1、开启网络监控功能（useJmx="true"）

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="localhost" dataDirectory="${activemq.data}" useJmx="true">

2、数据库持久化配置，注释掉之前kahadb消息存储器

<persistenceAdapter>  

    <jdbcPersistenceAdapter dataDirectory="${activemq.data}" dataSource="#mysql-ds" createTablesOnStartup="false" useDatabaseLock="true"/>  

</persistenceAdapter>

3、增加数据源mysql-ds

4、修改客户端上连接url为类似于failover:(tcp://0.0.0.0:61616,tcp://0.0.0.0:61617,tcp://0.0.0.0:61618)?randomize=false

注：默认情况下，failover机制从URI列表中随机选择出一个URI进行连接，这可以有效地控制客户端在多个broker上的负载均衡，但是，要使客户端首先连接到主节点，并在主节点不可用时只连接到辅助备份代理，需要设置randomize = false。

5、可以看到只有一台MQ成为Master，其余两台成为slave并会尝试成为Master，并不断重试。且两台slave的管理控制台将无法访问

Replicated LevelDB Store

ActiveMQ5.9以后才新增的特性，使用ZooKeeper协调选择一个node作为master。被选择的master broker node开启并接受客户端连接。 其他node转入slave模式，连接master并同步他们的存储状态。slave不接受客户端连接。所有的存储操作都将被复制到连接至Master的slaves。 

如果master死了，得到了最新更新的slave被允许成为master。推荐运行至少3个replica nodes。 

配置修改清单

1、 使用性能比较好的LevelDB替换掉默认的KahaDB

<persistenceAdapter>

    <replicatedLevelDB directory="${activemq.data}/leveldb" replicas="3" bind="tcp://0.0.0.0:62623" zkAddress="127.0.0.1:2181" hostname="localhost" zkPath="/activemq/leveldb-stores"/>

</persistenceAdapter>

配置项说明：

• directory：持久化数据存放地址
• replicas：集群中节点的个数
• bind：集群通信端口
• zkAddress：ZooKeeper集群地址
• hostname：当前服务器的IP地址，如果集群启动的时候报未知主机名错误，那么就需要配置主机名到IP地址的映射关系。
• zkPath：ZooKeeper数据挂载点

2、修改客户端上连接url为failover:(tcp://0.0.0.0:61616,tcp://0.0.0.0:61617,tcp://0.0.0.0:61618)?randomize=false

3、可以看到只有一台MQ成为Master，其余两台成为slave。且两台slave的管理控制台将无法访问。

LevelDB解释

Leveldb是一个google实现的非常高效的kv数据库，目前的版本1.2能够支持billion级别的数据量了。 在这个数量级别下还有着非常高的性能，采用单进程的服务，性能非常之高，在一台4核Q6600的CPU机器上，每秒钟写数据超过40w，而随机读的性能每秒钟超过10w。由此可以看出，具有很高的随机写，顺序读/写性能，但是随机读的性能很一般，也就是说，LevelDB很适合应用在查询较少，而写很多的场景。LevelDB应用了LSM (Log Structured Merge) 策略，通过一种类似于归并排序的方式高效地将更新迁移到磁盘，降低索引插入开销。

限制：1、非关系型数据模型（NoSQL），不支持sql语句，也不支持索引；2、一次只允许一个进程访问一个特定的数据库；3、没有内置的C/S架构，但开发者可以使用LevelDB库自己封装一个server；