这次真的忽略了一些ActiveMQ内心的娇艳

首先ActiveMQ有俩种消息队列模式：点对点和发布订阅，这俩种都有不可替代的应用场景，前者适用于消息唯一传递的业务，后者适用于分布式环境下进行多面数据同步的操作。

其次一些关于它的官方简介和安装步骤我就不占博客园数据库的内存了，写了也没啥鸟用，用烂的朋友想要提取点儿精华，没接触过的朋友请先安装一个玩玩点对点和发布订阅模式吧(http://www.cnblogs.com/1315925303zxz/p/6377551.html)，理解一下这俩种机制的区别和出现消息临界值时的特性，我下面也放一些我前期用于测试的Demo，其中总结了一些他们二者的主要区别，都是实战中必须要考虑的因素可以参考：

假设：存在一个消息生产者、多个消费者，分别在点对点和发布订阅模式下进行消息获取，当出现消息临界值的时候都有什么现象？这些需要朋友你自己体会，我能做的只有送上代码供各位测试了。

消息生产者

消息消费者(可以copy多个进行消息争抢测试)

注意事项：

1、生产者发送消息时必须支持事务，就是创建消息会话的时候设置为true，否则会出现“javax.jms.IllegalStateException: Not a transacted session”异常。消费者可以不支持。

2、点对点模式下，同一时刻只能有一个消费者从队列中获取消息内容，如果存在多个消费者，则会出现消息争抢现象直到消息全部抢完，处于阻塞状态，如果再有消息被放进来时，接着会进行争抢，但是只会有一个消费者获取到消息，不会出现多个消费者抢到消息的情况。

3、点对点模式下，生产者发送消息时，消费者可以处于离线状态，当消费者再次运行时可以接收到历史消息；但是在发布订阅模式下，消费者必须处于运行状态获取消息，历史消息也是不会被获取到的。

实战上线后踩过的坑以及解决方案：

1、用户订单入库成功后发送到MQ中的订单消息丢失，出现处理订单遗漏的情况？

解决方案1：打开消息持久开关。

因为Activemq支持两种消息传送模式：

PERSISTENT （持久消息）该模式是activemq默认的传送方式，此模式下可以保证消息只会被成功传送一次和成功使用一次，消息具有可靠性。在消息传递到目标消费者，在消费者没有成功应答前，消息不会丢失。所以很自然的，需要一个地方来持久性存储。如果消息消费者在进行消费过程发生失败，则消息会被再次投递；

 NON_PERSISTENT（非持久消息）该模式适用于消息不重要的，可以接受消息丢失的哪一类消息，这种消息只会被投递一次，消息不会在持久性存储中存储，也不会保证消息丢失后的重新投递。

与spring整合使用ActiveMQ配置文件如下：

解决方案2：设置消息重发机制。

ActiveMQ针对消息丢失情况提供了消息重发机制，假设消息发送失败，为了解决这一尴尬局面，我们可以在实际项目中配置消息重发机制，以防万一。

前天任务调度服务上线后，出现消息丢失的情况，根据以上解决方案是否能够根治这种情况，本人也是不太能够保证，希望稍后能在留言区得到各位老兄的帮助。