生活中的“消息队列”
1、流水线作业（削峰填谷）
工厂里的流水线作业中，有部分工序完成的速度是比较慢的，有部分工序是比较快的，最简单的方式就是在速度较慢的工序和速度较快的工序之间增加一个“仓库”，速度快的工序产品扔进仓库，速度慢的工序直接从“仓库”取，这个仓库就是消息队列。
2、解耦
生活中，要将某些通知以微信的方式发送给其他人，如果一个个私发，非常浪费时间，如果创建个群，在里面发一次消息，那其他人就可以收到了。这个建群就是消息队列，只要往群里发一条消息，大家都可以收到。
什么情况下使用消息队列呢？
1、功能耦合-----解耦
常见的支付流程如下：
上述流程同步进行，链路整体耗时300ms，如何能够降低支付流程的耗时？显然在支付流程中，“积分”和“短信”是跟“支付”不是强相关，且实时性要求不是那么高。如果将“支付”以后的消息发送给MQ，然后直接结束，这样整个链路也就100ms即可完成，随后下游订阅“积分”和“短信”进行消费。
2、波峰波谷-----削峰填谷
有如下场景：每天的下午6点到7点，某第三方平台会将用户信息（PDF文件）发送到核对系统，用来跟数据库进行核对。核对系统不要求实时性，三天内能处理好就行。
问题来了：核对系统却是24小时全天运行，而每天下午的6点到7点，核对系统要经历一场“洪峰”，显然，PDF文件流量是存在波峰波谷的（下午6-7点是波峰，其余都是波谷），但核对系统在波峰是超负荷运行，在波谷时空转。这时，需要一个“转储”工具，能够平衡PDF文件流量的波峰波谷，让核对系统能够高效运行。
通过一个消息队列，可以解决流量波峰波谷与系统处理能力之间的平衡，MQ能够转储下午6-7点的PDF文件，实现流量侧的“削峰填谷”，解决核对系统空转和高负荷宕机危险，实现核对系统全天高效运行。
3、异步
其实解耦和削峰填谷就是异步的过程。消息队列的核心就是异步。
使用消息队列要付出什么代价？
1、学习和使用成本
消息队列的默认模式很快就能搭好，但默认的并不一定符合系统需要，会有设置以及配置成本。
2、增加系统复杂性
增加一个组件会让系统变得复杂，因为要考虑一些其他问题：消息重复消费、可靠性传输、顺序消费等问题。
3、降低系统可用性
如果消息队列挂了，影响到下游的服务，很有可能造成整个系统都会挂掉。
4、问题排查难度增加
最直观的体现就是：如果出现问题的话，使用消息队列会让问题跟踪变得异常困难。你没法在IDE中看到所谓的调用层次，因为一旦你发送消息到队列里了，你就得自己去查找它在哪里处理的了，这就比较麻烦了
消息队列，要还是不要？
现在的经验仅想到以下两点，欢迎大家交流补充。
1、成本考虑
接入消息队列是需要学习和使用成本的，如果有其他方法能够解决，还是不要为了使用而使用。
2、业务场景
比如上述PDF文件这个例子使用消息队列是比较合理的，因为上下游对实时性不考虑，但有些考虑到实时性的，考虑消息队列就要慎重了