ActiveMQ是Apache软件基金会所研发开源的消息中间件，为应用程序提供高效的、可扩展的、稳定的和安全的企业级消息通信。
现在的消息队列有不少，RabbitMQ、Kafka、RocketMQ，ZeroMQ等等，而ActiveMQ作为拥有十多年历史的产品，有着许许多多的成功案例，活跃的社区，让它在消息中间件市场占有稳定的一席，据说ActiveMQ的下一代apollo拥有更好的性能。
ActiveMQ由java基于JMS1.1规范的实现，但是支持多种编程语言，如java、C、C++、C#、Python、PHP、Ruby等。
先看看ActiveMQ的架构图：
抛开网络服务（Network Services）不说，我们应该知道的是ActiveMQ的三个重要组成部分：连接（Connectors）、消息模式（Topic，Queue）、消息持久化方式。
连接（Connectors）
ActiveMQ提供了多种应用协议，如OpenWire、StompREST、WSNotification、XMPP、AMQP等，不同的协议有不同的特点，OpenWire用的比较多。
我们要在应用中使用ActiveMQ，根据JSM规范，需要获得一个JMS connection factory，然后再去创建connection，这个时候往往需要指定所使用的的协议。
消息模式
ActiveMQ提供了两种消息模式：点对点模式（Queue）、发布订阅模式（Topic），这两种模式基本上可以覆盖大部分的需求了。
1、点对点模式（Queue）
点对点模式使用队列作为中间媒介，这里的队列就是我们所理解的一个先进先出的一个结构，一个或者多个生产者将消息发送到队列，然后多个消费者从队列安装消息的先后顺序去消费，注意，队列中的消息只会被一个消费者接受所消费。
2、发布订阅模式（Topic）
发布订阅模式使用topic作为中间媒介，而topic可以认为就是一个广播站，当一个或者多个生产者将消息发布到topic广播站之后，topic广播站会往当前已经注册订阅的每一个消费者广播消息（这里的消费者我们称为订阅者），注意，这里每一个订阅者都会收到消息。
3、持久化订阅
在发布订阅模式中，topic在接收到消息之后，只会给当前已经注册订阅了的订阅者广播消息，那问题来了，如果因为某些原因，如网络问题，导致订阅者断开连接一段时间，而在这段时间内有接收新的消息，那对于那些暂时断开的订阅者，消息是不是就丢了呢？基于这种原因，ActiveMQ将订阅者分为持久化订阅者和非持久化订阅者。非持久化订阅者就是不接受离线时生产的消息，而持久化订阅者则是通过往ActiveMQ中注册一个表明自己身份的ClientId（每个订阅者都有一个ClientId，或自动生成，或自行指定），topic收到消息时，会为处于离线状态的持久化订阅者根据它的ClientId保存消息，当下次相同ClientId的订阅者连接时就可以得到它离线状态下topic收到的消息了。
4、死信队列
死信队列(Dead Letter Queue)用来保存处理失败或者过期的消息，简称DLQ。根据apache ActiveMQ官网的说明，当发生以下操作时，消息将会被重新发送给消费者：
1、在一个事务机制的会话中，调用会话的回滚rollback方法
2、在一个事务机制的会话中，未调用提交commit方法就关闭会话
3、会话使用CLIENT_ACKNOWLEDGE客户端签收模式时，调用会话的恢复recover方法
4、客户端连接超时（可能正在执行的代码花费的时间超过配置的超时时间）
当重发达到一定次数后（默认是6次，可配置），broker就会收到一个“Poison ACK”，俗称毒丸，接着broker就会将消息统一发送到一个队列，这个队列就是死信队列。
5、Advisory
Advisory是ActiveMQ提供的对生产者、消费者、队列、Topic、消息等等提供的一套消息监控和管理机制，它在一系列的事件发生后，将事件特点以消息的形式发送到特定的Queue或者Topic，监听这些Queue和Topic的消费者就可以收到消息，以此来完成自定义的消息监控及管理。
其实Advisory很常见，默认情况下，当你发送消息到ActiveMQ时，你就会发现ActiveMQ自动创建一些Topic，这些Topic就是Advisory，当然，你也可以配置使用Queue，以下是几个常见的Advisory：
| 名称 | 说明 |
| ActiveMQ.Advisory.Connection | 当连接建立或者断开时 |
| ActiveMQ.Advisory.Producer.Queue | 生产者往队列发送消息时 |
| ActiveMQ.Advisory.Producer.Topic | 生产者往Topic发送消息时 |
| ActiveMQ.Advisory.Consumer.Queue | 消费者从队列消费消息时 |
| ActiveMQ.Advisory.Consumer.Topic | 消费者从Topic消费消息时 |
更多信息，可以参考官网：http://activemq.apache.org/advisory-message
消息持久化方式
消息的持久化一般是为了避免消息丢失，即使服务器宕机重启之后，消息能自动恢复，而不是像内存数据一样被清除，当然，ActiveMQ也允许你使用内存来存储消息。
当前ActiveMQ默认的持久化方式是采用Kahadb，而目前主流讨论的持久化方案主要是：AMQ、Kahadb、JDBC、Leveldb、ReplicatedLeveldb。
| 持久化方式 | 说明 |
| AMQ | ActiveMQ5.3之前版本默认持久化方式，采用日志文件的存储方式，写入和恢复速度都很快 |
| Kahadb | Kahadb是一个专门针对消息持久化的解决方案，在ActiveMQ5.4及之后的版本默认采用的存储化方式，性能等各方面比AMQ更优 |
| JDBC | JDBC方式是将消息数据写入到数据库中，但是频繁的从数据库读取写入是一件很耗性能的事，于是在此方式的基础上又提出了Journal优化方案，使用高速缓存写入技术，当消费者消费速度跟不上生产者的生产速度时才写入数据库，这样大大提高了性能 |
| Leveldb | ActiveMQ5.8之后提出来持久化方式，和Kahadb很相似，但是性能比Kahadb更优，至于为什么不将Leveldb作为默认持久化方式，各种说法都有，还有，好像以后Leveldb以后将不会被支持了 |
| ReplicatedLeveldb | ReplicatedLeveldb是ActiveMQ和zookeeper整合时采用的持久化方式，一般在ActiveMQ做集群部署时用到 |
持久化方式还有很多，只要你愿意，ActiveMQ允许你将消息存储在内存中，甚至你还可以自行实现持久化方式。
结语
这里只是简单的介绍认识了一下ActiveMQ，当然，ActiveMQ肯定不会只有这么点东西，这不是一篇简单的博文能说完的，像ActiveMQ还有单机和集群的部署方案，对于集群，可能还有负载均衡，而死信策略只是众多的策略之一，还有消息转发策略、消息恢复策略、消息剔除策略等等，再比如ActiveMQ账号权限控制，也是可以学习了解的方面，只不过这些东西可能需要项目经验慢慢积累了。
更多信息可以查看ActiveMQ的官网介绍：http://activemq.apache.org