消息队列大概是基于什么设计模式呢，它大概有什么作用嘞。本篇会比较基础的简单介绍他们。
一.消息模型
- 点对点
消息生产者向消息队列中发送消息，只能被消费一次
- 发布/订阅和观察者模式有以下不同
- 观察者模式中，观察者和主题都知道对方的存在，而发布订阅模式中，生产者和消费者不知道对方的存在，他们通过频道通信
- 观察者模式是同步的，当时间触发时，主题会调用观察者方法，然后等待方法返回。而发布与订阅模式是异步的，生产者向频道发送一个消息后，就不需要关心消费者何时去订阅这个消息，可以立即返回。
二.使用场景
异步处理
发送者将消息发送给消息队列之后，不需要同步等待消息接收者处理完毕，而是立即返回进行其它操作。消息接收者从消息队列中订阅消息之后异步处理。例如在注册流程中通常需要发送验证邮件来确保注册用户身份的合法性，可以使用消息队列使发送验证邮件的操作异步处理，用户在填写完注册信息之后就可以完成注册，而将发送验证邮件这一消息发送到消息队列中。
只有在业务流程允许异步处理的情况下才能这么做，例如上面的注册流程中，如果要求用户对验证邮件进行点击之后才能完成注册的话，就不能再使用消息队列。
后续可以添加更多的例子:
日志处理消息通讯（聊天室等）流量削峰
在高并发的场景下，如果短时间有大量的请求到达会压垮服务器。可以将请求发送到消息队列中，服务器按照其处理能力从消息队列中订阅消息进行处理。
应用解耦
如果模块之间不直接进行调用，模块之间耦合度就会很低，那么修改一个模块或者新增一个模块对其它模块的影响会很小，从而实现可扩展性。通过使用消息队列，一个模块只需要向消息队列中发送消息，其它模块可以选择性地从消息队列中订阅消息从而完成调用。
三.可靠性
发送端的可靠性
发送端完成操作后一定能将消息成功发送到消息队列中。实现方法：在本地数据库建一张消息表，将消息数据与业务数据保存在同一数据库实例里，这样就可以利用本地数据库的事务机制。事务提交成功后，将消息表中的消息转移到消息队列中，若转移消息成功则删除消息表中的数据，否则继续重传。
接收端的可靠性
接收端能够从消息队列成功消费一次消息。两种实现方法：
保证接收端处理消息的业务逻辑具有幂等性：只要具有幂等性，那么消费多少次消息，最后处理的结果都是一样的。
- 保证消息具有唯一编号，并使用一张日志表来记录已经消费的消息编号。
四.优缺点
优点
解耦: 每个成员不必受其他成员影响，可以更独立自主，只通过一个简单的容器来联系。
提速: 其实就是支持异步操作，能节约大量时间
广播: 新同伴新加入成本很低
削峰: 遇上突然的大量请求，只需要在多久时间内处理完成即可。缺点
引入复杂度: 需要地方防止，也需要考虑安全性。
暂时的不一致性: 这个很好理解，并不等于放入队列就是执行完成。其实还存在失败的可能性，如果保证顺序执行，且还能重复执行就是另个比较深的问题了。
五.应用场景
生产者不需要从消费者处获得反馈
容许暂时不一致性
产生副作用的效益高于成本