1、背景

比如我们用户注册，假设注册完后需要发送短信给用户或者提醒应用管理员，那么总不可能在一个接口中又注册，又发短信，又发邮件，所以也可以引入消息队列，注册成功后登记发短信发邮件的消息后就返回给前端。后面消费程序慢慢去发短信和邮件。这也是用消息队列来进行异步化提高系统性能，异步目的就是减少请求响应时间，实现非核心流程异步化，提高系统相应性能。

再比如我们经常会遇到类似授权获取用户信息的功能，比如用户进入页面，首先跳转到微信去授权登录获取code，然后我们的页面把code通过接口请求微信接口获取openid等信息。此时如果直接在接口里面调用微信的接口（或者其它第三方接口），然后前端等着接口返回，如果第三方接口比较耗时，那么接口服务器会一致占据这个线程，知道第三方返回或者超时，这种业务场景严重影响了接口服务器处理其它请求。我们可以引用消息队列，在接口服务器获取code后，登记消息到消息队列，直接返回个流水号给前端，然后消费程序获取code后再去调用第三方接口，返回结果后存入缓存中，前端根据流水号定时查询结果即可。这是用消息队列来进行异步处理的一种场景。

这里虽然也是核心流程，异步化的原因是因为调用了第三方，而第三的系统性能是未知的，所以为了不影响接口服务的性能，进行了异步化处理。其实也用了解耦思想，毕竟对于这种登录的场景，一个系统中可能会有多种登录，比如企微登录，微信登录，QQ登录，各种第三方对接的合作方登录授权，我们都可以抽取成这种模式。

1、前端请求获取第三方的code

2、调用登录接口传入code，返回流水号

3、根据流水号轮询调用接口查询登录结果

4、若轮询次数超过限制则提示超时。

后续要新增对对接方，只需要修改消费程序即可。

再比如用户下单，下单成功后，要调用库存系统扣减库存，要调用第三方系统推送订单，如果这些逻辑都写在接口里，后续新增业务场景，要把订单信息推送给更多的第三方，或者更具订单信息搞营销活动给用户赠送权益岂不是接口N行代码？所以这种业务场景一定要引入MQ消息队列来解耦，下单完就登记消息，要消费消息的系统直接跟消息队列对接即可，或者消息队列对接第三方系统。如果用RocketMQ的话还可以用分组消费模式，也就是多个消费者消费同一条消息。

总之来说，异步是为了提高性能，解耦是为了扩展和好修改。一部和解耦其实会有一部分重合的概念。

对于流量销峰，一个简单的业务场景就是秒杀或者抢购，如果直接打到数据库，数据库扛不住，那么我们用消息队列中消费者来跟数据库打交道做秒杀库存扣减逻辑，这样相当于让前端请求排队处理了，前端异步查询结果，虽然这里也起了异步的作用，但是业务本身的目的是为了流量销峰。对于秒杀这些场景，如果用户不是太大，比如并发几千上万而已，那么也可以用redis来做库存控制。但是最终还是会到数据库的，如果库存多的话，所以用消息队列加redis双重来做控制，那么几乎可以应对大多数秒杀业务场景。

2、场景

下单、注册、秒杀、抽奖等。

3、技术选型

RocketMQ、Kafka、Pulsar、RabbitMQ、NSQ