1.activemq的几种通信方式publish(发布)-subscribe(订阅)(发布-订阅方式)发布/订阅方式用于多接收客户端的方式.作为发布订阅的方式，可能存在多个接收客户端，并且接收端客户端与发送客户端存在时间上的依赖。一个接收端只能接收他创建以后发送客户端发送的信息。作为subscriber,在接收消息时有两种方法，destination的receive方法，和实现messagelistener接口的onMessage方法。p2p(point-to-point)(点对点)p2p的过程则理解起来比较简单。它好比是两个人打电话，这两个人是独享这一条通信链路的。一方发送消息，另外一方接收，就这么简单。在实际应用中因为有多个用户对使用p2p的链路。在p2p的场景里，相互通信的双方是通过一个类似于队列的方式来进行交流。和前面pub-sub的区别在于一个topic有一个发送者和多个接收者，而在p2p里一个queue只有一个发送者和一个接收者。2.activemq如果数据提交不成功怎么办(消息丢失)1.publish(发布)-subscribe(订阅)方式的处理发布订阅模式的通信方式，默认情况下只通知一次，如果接收不到此消息就没有了。这种场景只适用于对消息送达率要求不高的情况。如果要求消息必须送达不可以丢失的话，需要配置持久订阅。每个订阅端定义一个id，
和接收消息时需要配置发送模式为持久化template.setDeliveryMode(DeliveryMode.PERSISTENT);。此时如果客户端接收不到消息，消息会持久化到服务端(就是硬盘上)，直到客户端正常接收后为止。1.4.2p-p(点对点)方式的处理点对点模式的话，如果消息发送不成功此消息默认会保到activemq服务端直到有消费者将其消费，所以此时消息是不会丢失的。3.如何解决消息重复问题所谓消息重复,就是消费者接收到了重复的消息,一般来说我们对于这个问题的处理要把握下面几点,①.消息不丢失(上面已经处理了)②.消息不重复执行一般来说我们可以在业务段加一张表,用来存放消息是否执行成功,每次业务事物commit之后,告知服务端,已经处理过该消息,这样即使你消息重发了,也不会导致重复处理大致流程如下:业务端的表记录已经处理消息的id,每次一个消息进来之前先判断该消息是否执行过,如果执行过就放弃,如果没有执行就开始执行消息,消息执行完成之后存入这个消息的id4.大量的消息每页被消费，能否发生oom异常？可以控制每个消息队列中数据的大小，不允许无线填充数据，避免该队列多大，导致过...
