它也是比较古老的消息队列，虽然最近新版本改名为Artemis，也不能去掉它身上沧桑的味道。就这么一个重量级的东西，在很多公司尾大不掉，具体架构设计让我为你娓娓道来。或许你应该从人性上，而不是技术上，来考虑一下它的存在性。

以下是正文。

1、架构设计概要

ActiveMQ提供两种可供实施的架构模型：“M-S”和“network bridge”;其中“M-S”是HA方案，“网络转发桥”用于实现“分布式队列”。

1.1、M-S

Master-Slave模型下，通常需要2+个ActiveMQ实例，任何时候只有一个实例为Master，向Client提供”生产”、“消费”服务，Slaves用于做backup或者等待Failover时角色接管。

M-S模型是最通用的架构模型，它提供了“高可用”特性，当Master失效后，Slaves之一提升为master继续提供服务，且Failover之后消息仍然可以恢复。(根据底层存储不同，有可能会有消息的丢失)。

有以下两方面要点：

第一，M-S架构中，涉及到选举问题，选举的首要条件就是需要有“排它锁”的支持。排它锁，可以有共享文件锁、JDBC数据库排它锁、JDBC锁租约、zookeeper分布式锁等方式实现。这取决你的底层存储的机制。

第二，M-S架构中，消息存储的机制有多种，“共享文件存储”、“JDBC”存储、“非共享存储”等。不同存储机制，各有优缺点。在使用的时候一定要权衡。

1.2、网络转发桥(network bridge)

无论如何，一组M-S所能承载的消息量、Client并发级别总是有限的，当我们的消息规模达到单机的上限时，就应该使用基于集群的方式，将消息、Client进行分布式和负载均衡。

ActiveMQ提供了“网络转发桥”模式，核心思想是：

1、集群中多个broker之间，通过“连接”互相通信，并将消息在多个Broker之间转发和存储，提供存储层面的“负载均衡”。

2、根据Client的并发情况，对Client进行动态平衡，最终实现支持大规模生产者、消费者。

这和Kafka的核心思想是相似的。