MQ的几种消息传递方式
发布订阅模式
发布订阅模式有点类似于我们日常生活中订阅报纸。每年到年尾的时候，邮局就会发一本报纸集合让我们来选择订阅哪一个。在这个表里头列了所有出版发行的报纸，那么对于我们每一个订阅者来说，我们可以选择一份或者多份报纸。比如北京日报、潇湘晨报等。那么这些个我们订阅的报纸，就相当于发布订阅模式里的topic。有很多个人订阅报纸，也有人可能和我订阅了相同的报纸。那么，在这里，相当于我们在同一个topic里注册了。对于一份报纸发行方来说，它和所有的订阅者就构成了一个1对多的关系。这种关系如下图所示：
点对点模式
点对点模式就相当于打电话，由两端的双方独享这一通信链路
扩展的对点模式
和前面两种方式比较起来，request-response的通信方式很常见，但是不是默认提供的一种模式。在前面的两种模式中都是一方负责发送消息而另外一方负责处理。而我们实际中的很多应用相当于一种一应一答的过程，需要双方都能给对方发送消息。于是请求-应答的这种通信方式也很重要。它也应用的很普遍。
请求-应答方式并不是JMS规范系统默认提供的一种通信方式，而是通过在现有通信方式的基础上稍微运用一点技巧实现的。下图是典型的请求-应答方式的交互过程：
我在项目中的理解
MQ其实就是一个消息中转站。
在企业级的应用里，会有一个服务器集群来作为这个中转站，这个集群中有主从，有备份，有路由，有网关。此时MQ就是就是一种中间件，在个人的实验中体会不到这种感觉。
企业级的MQ不仅仅实现了简单的消息中转站的功能，还实现了消息生产者和消息消费者的认证功能（即他们能消费和生产哪些具体的topic）。
附一张企业MQ的架构图
MQ的缺点
- mq的主要问题在于重复生产和重复消费(延迟也是一个很大的缺点，但是这可以换来性能上的提升，监听获取信息肯定比轮询获取信息的效率高)。
- 比如几个业务系统需要消费一个点对点模式的mq消息，其中一个业务系统消费成功了但是并没有向mq服务器成功发送消费成功的确认ack，导致消息在mq服务器中依然存在，从而导致其他业务系统的重复消费。
- 再比如生产者如果没有接收到mq服务器的确认消息，就会重复生产，如果在服务器没有相应的去重措施，就会带来很大的隐患。
- 所以在使用MQ的时候，最重要的问题不是在于怎么去用它，而是怎么在业务系统中解决重复生产和重复消费的问题。具体的得根据系统允许的容错率和业务来进行相应的处理。
- 我主要说一下在服务器端对MQ进行去重的方法，如果是同一topic的信息，可以通过对消息内容进行摘要运算从而达到简单的去重效果。
实现可靠MQ和去重参考方法
消息的可靠性设计，目前有2种模式：模式1是采用Notify的方式，先发送半消息，业务操作成功后最后提交完整消息，同时提供业务操作的检查接口，这种模式实现消息的最终一致性；模式2将业务数据和消息数据先都存在业务数据库里面，通过数据库的事务保证一致性，随后将消息转发给MQ。模式1的缺点是业务侵入性高，方案比较复杂，需要重新实现；模式2的缺点是消息数据可能会散落在各个地方，包括业务系统，而且可以集成现有MQ。
消息去重设计，也有2种模式：模式1是消费者根据自己的业务实现去重，模式2是在消费者端增加一个数据库表专门记录已经消费过的消息，不需要消费者根据业务去做去重。
