应用场景
异步、削峰、解耦，三点一定烂熟于心
例：电商购物
graph TD
下单 --> 支付
支付 --> 优惠券
优惠券 --> 积分
积分 --> 短信
短信 --> 结束
异步解耦：
实际流程可能更长，不可能真的等几秒十几秒下一单，因此我们需要同时做这些事。也就是异步。
至于异步为什么不适用多线程？
订单流程，经理扣积分，扣优惠券，发短信，扣库存等等业务，要调用这么多的接口，流程每次加减一个步骤要修改接口的调用还需要重新发布系统，耦合度过高，问题排查困难。
graph TD
下单 --> 支付
支付 --> MQ发送消息
MQ发送消息 --> 优惠券
MQ发送消息 --> 积分
MQ发送消息 --> 短信
MQ发送消息 --> 结束
支付成功的消息告诉别的系统，他们收到了去处理，你只用走完自己的流程，把自己的消息发出去，那后面要接入什么系统都很简单，直接订阅你发送的支付成功消息，你发布支付成功的消息，新系统负责监听。
削峰
秒杀活动00 ：00的时候流量疯狂怼进来，服务器中Redis，MySQL各自的承受能力都不一样，全部流量照单全收肯定有问题，很可能会挂掉。
因此可以把请求放到队列里面，至于每秒消费多少请求，就看自己的服务器处理能力，你能处理5000QPS你就消费这么多，可能会比正常的慢一点，但是不至于打挂服务器，等流量高峰下去了，你的服务也就没压力了。
消息队列缺点
系统复杂性
简单的一个系统，接入一个中间件在那，要去维护他，使用的过程中要考虑各种问题，比如消息重复消费、消息丢失、消息的顺序消费等等。
数据一致性
下单的服务自己保证自己的逻辑成功处理了，成功发了消息，但是优惠券系统，积分系统等等这么多系统，他们成功失败不能确定
所有的服务都成功才能算这一次下单是成功的，那怎么才能保证数据一致性呢？
分布式事务：把下单，优惠券，积分。。。都放在一个事务里面一样，要成功一起成功，要失败一起失败。
可用性
消息队列mq挂了就不可用了。
技术选型： Kafka、RocketMQ
