activemq mysql 集群配置_activeMQ主要的几类主从集群部署方式

一、activeMQ主要的几类部署方式比较

1、默认的单机部署(kahadb)

activeMQ的默认存储的单机方式，以本地kahadb文件的方式存储，所以性能指标完全依赖本地磁盘IO，不能提供高可用。

2、基于zookeeper的主从(levelDB Master/Slave)

5.9.0新推出的主从实现，基于zookeeper来选举出一个master，其他节点自动作为slave实时同步消息。

因为有实时同步数据的slave的存在，master不用担心数据丢失，所以leveldb会优先采用内存存储消息，异步同步到磁盘。所以该方式的activeMQ读写性能都最好，特别是写性能能够媲美非持久化消息。

优点：

实现高可用和数据安全

性能较好

缺点：

因为选举机制要超过半数，所以最少需要3台节点，才能实现高可用。

3、基于共享数据库的主从(Shared JDBC Master/Slave)

可以基于postgres、mysql、oracle等常用数据库。

每个节点启动都会争抢数据库锁，从而保证master的唯一性，其他节点作为备份，一直等待数据库锁的释放。

因为所有消息读写，其实都是数据库操作，activeMQ节点本身压力很小，性能完全取决于数据库性能。

优点：

实现高可用和数据安全

简单灵活，2台节点就可以实现高可用

缺点：

稳定性依赖数据库

性能依赖数据库

比较得知，采用基于zookeeper的主从(levelDB Master/Slave)模式

采用这种模式的关键配置地方在与每个activemq.xml文件中下面位置：

下面的配置在三个实例上保持一致，除了标红部分，主要修改配置文件conf/activemq.xml。(1)broker-name的统一将broker标签的brokerName属性设置为统一的值，我将这个值设置为“test”，只有三个实例的brokerName一致，zookeeper才能识别它们属于同一个集群(2)persistenceAdapter的配置persistenceAdapter设置持久化方式，主要有三种方式：kahaDB(默认方式)、数据库持久化、levelDB(v5.9.0提供支持)本文采用levelDB来进行持久化，并使用zookeeper实现集群的高可用，配置如下：首先注释掉原来kahaDB的持久化方式，然后配置levelDB+zookeeper的持久化方式。

把标签中 kahaDB 改成 LevelDB 方式，具体如下：

更改前：

更改后：

... 注释掉这部分的持久化方式。配置增加下面的持久化方式：...

注意：replicas是主从服务器的总数量hostname配置成当前服务器的物理ip即可。zkAddress是全部zookeeper集群的所有ip及端口。bind是绑定本机网卡的物理ip，想省事就写0.0.0.0 表示本机全部网卡

然后启动三台服务器activemq就可以了.

以事务方式提交Session session = connection.createSession(true, Session.SESSION_TRANSACTED);生成完后最后再加上一句session.commit();测试效率每秒10000条左右，完全满足设计要求。

本文出自http://blog.csdn.net/ziele_008/article/details/51883012