小强哥博客

小强哥,小强哥博客,技术大咖

activeMQ主要的几类集群部署方式

ActiveMQ主要的几类部署方式比较

默认的单机部署(kahadb)

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

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

5.9.0新推出的主从实现,基于zookeeper来选举出一个master,其他节点自动作为slave实时同步消息。 因为有实时同步数据的slave的存在,master不用担心数据丢失,所以leveldb会优先采用内存存储消息,异步同步到磁盘。所以该方式的activeMQ读写性能都最好,特别是写性能能够媲美非持久化消息。

优点: 实现高可用和数据安全、性能较好。

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

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

可以基于postgres、mysql、oracle等常用数据库。 每个节点启动都会争抢数据库锁,从而保证master的唯一性,其他节点作为备份,一直等待数据库锁的释放。 因为所有消息读写,其实都是数据库操作,activeMQ节点本身压力很小,性能完全取决于数据库性能。

优点: 实现高可用和数据安全,简单灵活,2台节点就可以实现高可用。

缺点: 稳定性依赖数据库,性能依赖数据库。

性能测试

用同一台测试机作为master。测试代码为java,使用activemq-client-5.11.1提供的client,每个线程用一个连接反复写/读,所有线程完毕后,汇总测试结果。 每秒写/读吞吐量测试结果如下(测试机性能较差,测试结果仅仅用来做3种部署方式的横向比较): 150/500表示每秒写入150条,读取500条消息。

#单线程10线程20线程40线程
单机(kahadb)150/500350/2000500/2000480/2000
基于zk的主从(leveldb)180/3000600/55001400/60003200/4500
基于共享数据库的主从160/300250/1050250/1150250/1200

灾备方案(两种方式都已经测试通过)

leveldb方式

需要3台节点,2台在主机房,1台在备机房,主机房的节点权重设的比备机房节点高。 当master节点故障: 因为权重的关系,主机房另一个节点会自动被选举为新的master。 当主机房故障: 需要启动备用机房时,先更改备机房节点配置,把集群规模从3改成1,这样1个节点可以临时提供服务(此时不再保证高可用)。

共享数据库方式

3台节点即可,2台在主机房,1台在备机房,备机房节点指向灾备activeMQ数据库,平时要关闭。 当master节点故障: 主机房的另一个节点会自动取得数据库锁,成为新的master。 当主机房故障: 需要启动备用机房时,先完成activeMQ数据库的切换,然后启动灾备activeMQ节点即可临时外提供服务(此时不再保证高可用)。