在单体应用中，我们常常使用简单的数据结构——队列，来解决一些实际问题，比如生产者消费者模式使用队列作为中间传输。在复杂的分布式环境中，简单队列是无法解决分布式环境一定存在的问题，比如应用之间的通信、消息持久化、消息传输控制等等问题。消息队列又能解决那些问题呢？
1.异步处理
举个例子：在商城系统中，订单系统下单成功后，需要一些后处理，比如扣减库存、统计销售数量、短信通知、消息推送、优惠卷占用等等。如果所有这些操作都是同步处理，那下单耗时非常严重，影响用户体验。可以利用消息队列将这些同步操作改为向各个系统发送消息，接口直接返回订单信息。
2. 流量控制（削峰填谷）
我们的应用处理请求能力是有限，在一些存在海量请求的场景中，比如秒杀、抢购等等。如果直接处理这海量请求，可能我们的应用早挂掉了。这时候可以把这些请求丢进消息队列中，下游系统以自己的处理能力消费这些消息，起到了削峰填谷的作用。
3. 应用间解耦
下游应用依赖上游应用，如果在代码每个地方都依赖，这样维护应用之间的依赖关系非常头疼。比如电商系统中常见的订单状态，有许多下游系统依赖订单系统，订单状态可能是待付款、待发货、待收货等等。如果订单状态每次变更都在订单系统中调用其他系统，那么维护订单系统的人肯定还在加班（哈哈）。如果所有的订单状态变更状态处理都在订单系统，那么应用之间的耦合度太高。这时候可以使用消息队列这把利器，可以利用消息队列中主题-订阅模式，订单状态发生变化只需要发送消息，而需要处理订单状态变更的系统只需订阅订单状态变更的Topic。这样订单系统与其他系统就不是强耦合。
4. 总结
消息队列的典型应用场景：异步处理、流量控制、应用间解耦。除此之外消息对了还可以：
- 作为发布 / 订阅系统实现一个微服务级系统间的观察者模式；
- 连接流计算任务和数据
- 将消息广播给大量消费者
消息队列不是银弹，引入消息队列也会存在一些问题： - 消息延迟
- 数据可能不一致
- 增加系统复杂度
所以我们一定要根据自身的业务特点选择是否使用消息队列。
