1.消息队列在你项目中起到什么作用？
从以前的单体架构到现在的微服务架构，成百上千的服务之间相互调用和依赖。从互联网初期一个服务器上有 100 个在线用户已经很了不得，到现在坐拥10亿日活的微信。我们需要有一个「东西」来解耦服务之间的关系、控制资源合理合时的使用以及缓冲流量洪峰等等。它常用来实现：异步处理、服务解耦、流量控制。
异步处理
随着公司的发展你可能会发现你项目的请求链路越来越长，例如刚开始的电商项目，可以就是粗暴的扣库存、下单。慢慢地又加上积分服务、短信服务等。这一路同步调用下来客户可能等急了，这时候就是消息队列登场的好时机。
调用链路长、响应就慢了，并且相对于扣库存和下单，积分和短信没必要这么的 "及时"。因此只需要在下单结束那个流程，扔个消息到消息队列中就可以直接返回响应了。而且积分服务和短信服务可以并行的消费这条消息。可以看出消息队列可以减少请求的等待，还能让服务异步并发处理，提升系统总体性能。
服务解耦
除了加积分服务和短信服务，这时候可能又要来个营销服务，或者要丢掉某些服务。为了迎合这些下游系统订单服务需要经常地修改，任何一个下游系统接口的变更可能都会影响到订单服务。这样的话订单系统的维护成本就⾮常的⾼，要时时刻刻考虑其他关联系统如果出现故障该怎么办？A 系统是发还是先把消息保存起来呢？选用消息队列来解决系统之间耦合的问题，订单服务把订单相关消息塞到消息队列中，只负责⽣产数据，不需要考虑消息被哪个系统来消费。
流量控制
A 系统调⽤ B 系统处理数据，每天 0 点到 12 点，A 系统⻛平浪静，每秒并发请求数量就 100 个。结果每次⼀到12 点 ~ 13 点，每秒并发请求数量突然会暴增到 1 万条。但是 B 系统最⼤的处理能⼒就只能是每秒钟处理 1000 个请求，这样系统很容易就会崩掉。这种情况可以引⼊消息队列，把请求数据先存⼊消息队列中，消费系统再根据⾃⼰的消费能⼒拉取消费。
2.常见消息队列的模式？
RabbitMQ 采用队列模型，RocketMQ和Kafka 采用发布/订阅模型。
1.队列模型
生产者往某个队列里面发送消息，一个队列可以存储多个生产者的消息，一个队列也可以有多个消费者， 但是消费者之间是竞争关系，即每条消息只能被一个消费者消费。
2.发布/订阅模型
发布/订阅模型是为了解决一条消息能被多个消费者消费的问题。该模型是将消息发往一个Topic即主题中，所有订阅了这个 Topic 的订阅者都能消费这条消息。
其实可以这么理解，发布/订阅模型等于我们都加入了一个群聊中，我发一条消息，加入了这个群聊的人都能收到这条消息。那么队列模型就是一对一聊天，我发给你的消息，只能在你的聊天窗口弹出，是不可能弹出到别人的聊天窗口中的。
讲到这有人说，那我一对一聊天对每个人都发同样的消息不就也实现了一条消息被多个人消费了嘛。
是的，通过多队列全量存储相同的消息，即数据的冗余可以实现一条消息被多个消费者消费。RabbitMQ 就是采用队列模型，通过 Exchange 模块来将消息发送至多个队列，解决一条消息需要被多个消费者消费问题。这里还能看到假设群聊里除我之外只有一个人，那么此时的发布/订阅模型和队列模型其实就一样了。
小结一下
队列模型每条消息只能被一个消费者消费，而发布/订阅模型就是为让一条消息可以被多个消费者消费而生的，当然队列模型也可以通过消息全量存储至多个队列来解决一条消息被多个消费者消费问题，但是会有数据的冗余。
