分布式系统基础-消息队列之ActiveMQ

ActiveMQ是J2EE中 JMS消息通信规范的一个实现，也是目前还在活跃和发展的最古老的第一代MQ，自从2004年成熟以后就迅速传播开来，经过多年的发展，逐步奠定了它在Java/J2EE圈子里的开源霸主地位，可谓生生不息。

ActiveMQ除了作为独立的消息中间件使用，还经常在某些ESB （Enterprise Service Bus）产品中作为总线基础设施（ Bus Infrastructure）存在，比如Apache ServiceMix与 Mule ESB。此外，很多产品也都采用ActiveMQ来实现消息传输功能，例如Apache Geronimo Tomee， Tomcat的企业版则使用ActiveMQ作为JMS的实现。ActiveMQ的发展目前主要受RedHat的推动，背后最直接的原因是RedHat的商业产品JBossA-M Q是基于ActiveMQ (ActiveMQ Artemis) 而构建的。

ActiveMQ完全支持JMS1.1规范，也支持多种语言的客户端如Java、C、C++、C#、Ruby、Perl、Python、PHP。在设计方面，ActiveMQ采用了可插拔的体系结构，因此可以支持多种传输协 议（in-VM、TCP、SSL、NIO、UDP）；支持包括文件、KahaDB、数据库及内存存储在内的多种消息存储方式。这里值得一提的是KahaDB，，它是专门用于存储消息的类数据库存储引擎，在支持事物的同时可提供很高的性能，因此在AcitveMQ 5.0以后就被作为其默认的消息存储引擎了，KahaDB还支持包括AMQP、MQTT、OpenWire、Stomp在内的多种消息协议。

在新一代消息中间件的冲击下，ActiveMQ这个元老级的项目也在不断尝试研发下一代产品，Apache Apollo项目就是其中的一个尝试，它是ActiveMQ的一个简化版本，在去掉J2EE里一些复杂特性的同时增加了对多种消息协议的支持，同时改用Scala语言编写，后来JBoss也加入进来，贡献了自己的HometQ源码，于是融合ActiveMQ、Apollo及HoraetQ三大MQ经验与优点的真正下一代开源产品诞生了，它的名字叫作ActiveMQ Artemis (Artemis是太阳神Apollo的孪生妹妹，他们在诞生之后就相互争夺老大的位置)。Artemis的关键目标是设计并实现一个超高性能的非阻塞内核架构，同时把上述三大M Q的闪耀功能都集于一身，成为Java领域再也无法超越的M Q之王，下面看看官方给出的特性列表。

1. 支持多种消息协议：AMQP、MQTT、OpenWire、Stomp及HometQ协议。
2. 支 持JM S1.1与 2.0规范，可通过JMX管理。
3. 支持灵活的集群模式。
4. 支持多种高可用方案，包括共享存储模式的高可用方案及消息复制（replication）方式的高可用方案。
5. 支持大消息、消息组 （Message Group)、最新值队列（Last-Value Queue)。
6. 支持Producer/Consumer的流量控制。
7. 更多其他特性。

如下所示是Artemis的架构组成示意图，我们看到它明显分为三层：消息存储层(Persistence)、核心引擎（A rtem isS ever)及协议层（ProtocolManager)，而 JMS兼容则变成了外围的功能模块(JMS Facade) 了。

ActiveMQ支持流量控制的高级功能也被带入Artemis中，除了支持 Window based flow control （类似TCP滑动窗口机制）模式的流量控制方式，还支持Rate limited flow control （基于消息收发速率 ）的流量控制方式。下面我们举例说明流量控制的一个应用场景：假如某个Queue上有两个Consumer共同处理消息，其中一个Consumer速度很慢，由于ActiveMQ会采用轮询的方式将消息分别发送到两个Consumer的缓冲Buffer里等待处理，所以当快速的Consumer处理完成所有消息而处于空闲状态时，慢速的 Consumer很可能积压了一些消息在自己的Buffer里来不及处理，在这种场景下，最好的办法是将consumerWindowSize设置为0，以防止消息在慢速的Consumer端积压。

我们来说说ActiveMQ的集群方案。首先来看看单一 Broker(ActiveMQ Server)情况下的 HA 高可用方案，主要是消息存储的高可靠性问题。下图给出了两种候选方案：如果企业有共享存储设备，则可以采用如下左图所示的共享文件存储的HA方案，类 似 Oracle RAC机制；否则可以采用如下右图所示的基于复制 replication) 的HA方案，类 似 MySQL主从复制。

在基于共享文件存储的HA方案里，消息存储采用了 KahaDB引擎，下面给出了此模式的集群示意图，这也是最简单、最可靠的企业级方案，因此成为ActiveMQ的默认配置。此外，基于数据库存储的H A也可以当作共享存储的一种特例。

而基于消息复制的HA方案要复杂得多，因为涉及多个存储节点之间的消息复制机制及Leader选举问题，在这种场景下毫无悬念地该轮到ZooKeeper出场了。如下图所示。

将9个ActiveMQ节点分为三组（brokerName1、brokerName2、brokerName3），每组都有三个ActiveMQ服务节点。另外准备三个节点的zookeeper服务集群，所有三个组九个ActiveMQ服务都共享这三个zookeeper服务节点（只是每组ActiveMQ所设置的zkPath属性不一样）。

将每组的三个ActiveMQ服务节点做LevelDB + Zookeeper的热备方案（且设置replicas=2）。保证每组只有一个节点在一个时间内为Master状态。这样整个集群中的九个ActiveMQ服务节点就同时会有三个ActiveMQ服务节点处于Master状态。

将整个集群中所有ActiveMQ服务节点的高性能方案设置为“组播发现”，并都采用一个相同的组播地址（可以采用默认的组播地址）。这样三个处于Master状态的ActiveMQ服务节点就会形成一个高性能方案（处于Salve状态的节点不会发出组播消息）。

除了上面所说的Broker的 HA集群，ActiveMQ还有强大的Networks of Borkers集群方案，可以看作 A ctiveM Q的 Distributed Queues or T opics的分布式集群解决方案。在如下所示的ActiveMQ集群拓扑图里 Producer连接到互为主备的broker-hubl/broker-hub2上，所有消息被分散到后端的3 个 broker (brokerl/2/3)上，由 3 个 Consumer消费，这样就分担了单个Broker的压力。

参考：架构揭秘从分布式到微服务