前置知识
消息队列最鲜明的特性是异步、削峰和解耦。这也是消息队列的适用场景和用途。
也有人说，日志处理和消息通讯可以看作是消息队列的具体落地案例，比如日志处理同时利用了消息队列的三个特性。
消息通讯指的是即时通讯之类的工具，比如使用的微信、QQ。通讯工具主要利用的是异步和解耦特性，如果觉得通讯工具有高并发的收发消息场景，也可以看作是削峰。
基本上一切消息队列的应用场景，都是围绕这三个特性来设计。反之，如果有一些需要用到异步、解耦和削峰的需求，消息队列也是最适合的工具。
此外，消息队列还可以用来实现事件驱动架构。
面试准备
公司有没有使用消息队列？主要解决什么场景的问题？
如果使用了消息队列，在具体的场景下不使用消息队列是否可行？和使用消息队列的方案比起来，有什么优缺点。
用的什么消息队列？有什么优缺点。
可以多找几个案例，来体现异步、解耦和削峰三个特性。
常见的面试问题：
有没有使用过消息队列？用来解决什么问题
是否听过延时队列？怎么实现延时队列？
如果涉及一个秒杀架构？回答的时候强调消息队列的作用
什么是事件驱动架构。
基本思路
首先，在简历上写的是擅长消息队列或是用消息队列解决问题
介绍案例后，可能的问题是：在具体的场景下，为什么必须使用消息队列。
下面列举几个引导性很强的场景回答：
秒杀场景
一个比较简单的秒杀架构图如图所示：
在消息队列前，要对用户请求做一些校验，比如这个用户是否参与过秒杀。其次要扣库存，扣库存成功才算抢到了。接着把这个请求丢到消息队列里，后续异步创建订单，并且完成支付。
这种设计的精髓在于利用消息队列把整个秒杀过程分为轻重两个部分：
在进入消息队列之前的操作都是轻量级的，一般是内存计算或是访问Redis，所以瓶颈基本取决于Redis的性能。
在进入消息队列后就是非常重量级的操作了，比如进一步验证交易的合法性、操作数据库等。
关键词：轻重之分
消息队列还经常被应用在秒杀场景里，最基本的架构就是秒杀请求进来以后，会有一个轻量级的服务。这个服务做一些限流、请求校验和库存扣减的事情，这些事情差不多都是内存操作，最多操作Redis。当库存扣减成功后，把秒杀丢到一个消息队列。
然后订单服务会从消息队列里把请求拿出来，真正创建订单，并且提示用户支付。这部分是重量级的操作，无法支持大规模并发。
所以在这个场景里，可以把消息队列看作是轻重操作的分界线。
