【消息队列】第一篇、为什么要用消息队列

用一个东西之前，我们得明白为什么要用他把？大致来说有以下三个场景。

场景一：异步处理

在一些代码层面会有复杂业务逻辑的处理，我们调用接口的延迟可能会特别长，这就导致了这类请求很容易发生超时的情况。例如上游系统下传数据，下游系统在接收数据的时候会有大量的SQL查询以及逻辑判断，这种情况下消息队列就是一个不错的选择。我们可以先把上游系统下传的数据接收到消息队列里面去，然后下游系统在根据自身的条件去消息队列里面拿数据处理。数据放入消息队列成功后，就可以返回成功的消息给上游系统了，这样就可以有效避免由于复杂逻辑导致的请求超时。
虽然异步操作会导致处理不及时的问题，但是现在市面上的大多消息队列都有push和pull两种模式。push模式采用的是发布/订阅模式，可以环节及时性的问题。

场景二：服务解耦

这个场景很好理解，比如有些数据上游系统只管下传，具体的消费者上游系统其实完全不用理会具体是哪一个下游系统去处理。今天可能是A系统在处理，明天可能又是B系统在处理。因此无论下游系统如何变化，上游系统都可以不需要做任何改动，只需要按时把数据放入消息队列中即可，剩下的处理就跟他没关系了。

场景三：流量控制

这个场景我就引用一下别人的解释把。

一个设计健壮的程序有自我保护的能力，也就是说，它应该可以在海量的请求下，还能在自身能力范围内尽可能多地处理请求，拒绝处理不了的请求并且保证自身运行正常。不幸的是，现实中很多程序并没有那么“健壮”，而直接拒绝请求返回错误对于用户来说也是不怎么好的体验。因此，我们需要设计一套足够健壮的架构来将后端的服务保护起来。我们的设计思路是，使用消息队列隔离网关和后端服务，以达到流量控制和保护后端服务的目的。