1 概述

Apache下的一个非常流行的消息中间件，使用JAVA支持的JMS Provider实现，所以和JAVA程序完全兼容，开发java项目中间件首选。当然ActiveMQ不仅仅支持JAVA，在C++、Dotnet、Python、Php、Ruby、Websocket等多种客户端都可以提供良好的服务。

ActiveMQ凭借其丰富的API、多种集群构建模式使得他成为业界老牌消息中间件，在中小型企业中应用广泛！

在实际的使用，activeMQ在高并发，高性能的应用中，会抛出JMSException，并且断开链接的情况，rabbitMQ是否能保持长链接状态，维持链接，避免资源消耗。

因此大规模、高并发的应用服务的消息中间件技术选型，譬如淘宝、京东这种大型的电商网站，尤其是双11这种特殊时间，ActiveMQ可能就显得力不从心了，就需要采用其他的消息中间件，例如 kafka、rabbitMQ等。

有兴趣的小伙伴可以关注一下官网，传送门如下：https://activemq.apache.org/

MOM（Message Oriented Middleware），分布式系统的集成，指的是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。

2 ActiveMQ原理

2.1 运行模型

• PTP点对点通信： 使用queue作为信息载体，满足生产者与消费者模式，一个消息只能被一个消费者使用，没有被消费的消息可以持久保持在queue 中等待被消费。
• Pub/Sub发布订阅模式： 使用Topic主题作为通信载体，类似于广播模式，在消息广播期间，所有的订阅者都可以接受到广播消息，在一条消息广播之后才订阅的用户是收不到该条消息的。

2.2 组成模块

• Broker:消息服务器，作为server提供消息核心服务。
• Producer:消息生产者，业务的发起方，负责生产消息传输给broker。
• Consumer:消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理。
• Topic:主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的广播。
• Queue:队列，PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的 queue完成指定消息的接收。
• Message:消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务 数据，实现消息的传输。

3 实用性分析

3.1 服务性能

ActiveMQ的性能一般，无法应对大规模、高并发应用服务的使用场景。

3.2 数据存储

• 默认采用kahadb存储（索引文件形式存储），也可以使用高性能的google leveldb（内存数据库存储）， 或者可以使用MySql、Oracle进程消息存储（关系型数据库存储）。

3.3 集群架构

ActiveMQ 可以与zookeeper进行构建 主备集群模型，并且多套的主备模型直接可以采用Network的方式构建分布式集群

4 集群模式

4.1 Master-Slave集群

Master-Slave集群.png

• Master-Slave：顾名思义，就是主从方式，当然这里要理解为主备的方式，也就是双机热备机制；Master Slave 背后的想法是，消息被复制到slave broker，因此即使master broker遇到了像硬件故障之类的错误，你也可以立即切换到slave broker而不丢失任何消息。 Master Slave是目前ActiveMQ推荐的高可靠性和容错的解决方案。
• 架构思考：Master-Slave集群模型的关键点：
  • 上图（Master-Slave）绿色的为主节点，灰色的则为备份节点，这两个节点都是运行状态的。
  • zookeeper的作用就是为了当绿色的主节点宕机时，进行及时切换到备份的灰色节点上去，使其进行主从角色的互换，用于实现高可用性的方案。
  • Master-Slave集群模型的缺点也显而易见，就是不能做到分布式的topic、queue，当消息量巨大时，我们的MQ集群压力过大，没办法满足分布式的需求

4.2 Network集群

Network集群.png

• Network：这里可以理解为网络通信方式，也可以说叫Network of brokers。这种方式真正解决了分布式消息存储和故障转移、broker切换的问题。可以理解消息会进行均衡；从ActiveMQ1.1版本起，ActiveMQ支持networks of brokers。它支持分布式的queues和topics。一个broker会相同对待所有的订阅（subscription）：不管他们是来自本地的客户连接，还是来自远程broker，它都会递送有关的消息拷贝到每个订阅。远程broker得到这个消息拷贝后，会依次把它递送到其内部的本地连接上。

• 架构思考：Network集群模型的关键点：

  • 首先，这种方案需要两套或多套（Master-Slave）的集群模型才可以搞定，部署非常麻烦，需要两套或多套集群直接相互交叉配置，相互间能够感知到彼此的存在。下面我给出一段XML配置，简单来说就是在ActiveMQ的配置文件里要进行多套（Master-Slave）之间的 networkConnector配置工作：

    <broker brokerName="receiver" persistent="false" useJmx="false">
        <transportConnectors>
            <transportConnector uri="tcp://localhost:62002"/>
        </transportConnectors>
        <networkConnectors>
            <networkConnector 
                  uri="static:( tcp://localhost:61616,tcp://remotehost:61616)"/>
        </networkConnectors>
    </broker>
    

  • 其次，Network虽然解决了分布式消息队列这个难题，但是还有很多潜在的问题，最典型的就是资源浪费问题，并且也可能达不到所预期的效果；通常采用Master-Slave模型是传统型互联网公司的首选，作为互联网公司往往会选择开箱即用的消息中间件，从运维、部署、使用各个方面都要优于ActiveMQ，当然ActiveMQ毕竟是 “老牌传统强Q”，Apache的顶级项目之一，目前正在进行新版本的重构（对于5.X版本）与落地，下一代 “Artemis代理”，也可以理解为 “6.X”。

5 相关信息

• 博文不易，辛苦各位猿友点个关注和赞，感谢