昨天做简历指导的时候，有个同学在实习项目里写：因为电商直播间爆火，短时间涌入大量订单，后台压力过大，所以引入MQ消息队列做流量削峰。

我告诉大家，这是明显的虚假项目描述。

如果面试的是中厂、大厂校招，一问就挂！

今天讲三点：

01  消息队列削峰场景很少

C端常规业务，几乎不存在MQ削峰的场景，90%同学都是瞎抄网课模板。

很多网课都会教一句话：瞬时流量太大，服务器扛不住，用MQ把请求存起来，慢慢消费，实现削峰填谷。

这句话单独看没有错，但它只讲了前半段，

MQ把流量堆积缓存起来之后，是需要持续消费、给用户反馈的，不是堆在队列里就万事大吉。

大家想一个真实的场景：直播间带货、电商下单，高峰期不是一秒钟爆量就结束了，而是持续两三个小时的高并发流量。

如果你真的用MQ削峰，流量源源不断往队列里堆，消费速度根本跟不上堆积速度，最后的结果就是：用户下完单，要等几十分钟、甚至几个小时才能收到下单成功的反馈。

这种用户体验，在商业化C端产品里是完全不成立的。

真正用到MQ削峰的场景极少，基本只局限于严格定点的瞬时秒杀活动，就连现在的双十一，都很少单纯靠MQ削峰了。

昨天写这个实习描述的还是个211的同学，明明学历有优势，结果硬生生靠错误的项目描述，把优质实习经历写成了一眼假的编造内容，真的太可惜了。

02  异步解耦是主场景

MQ最大的主要场景，从来不是削峰，而是异步解耦。

解耦主要就是异步化。

所谓异步，就是使用新的线程去调用一个方法、一个接口。我只要确认消息发送成功，主线程就可以直接结束响应、继续往下走，不用等待下游执行完毕。

这样做的核心目的，就是剥离非核心流程，拆分业务模块、降低业务耦合度，同时大幅提升接口响应速度。

但是不是所有的接口都能异步化：一般来说，只要是需要给用户返回结果的接口，基本都只能用同步。

还有同学问我：看到很多项目用Future接口，异步获取返回结果，是不是就能提升并发、实现解耦？

这种场景绝大部分也都是不合理的。

这种需要等待异步线程执行结果的写法，专业来说叫异步接口同步化。

什么是同步？代码一行行执行，跑完出结果再返回，这就是同步。

你用MQ、新开线程本来是为了解耦、不用等待结果，结果你又用Future强行等待线程执行完毕、拿到返回值。

那请问，解耦的意义在哪里？异步的意义在哪里？

这种写法，除了少数能并行执行的特殊场景，性能和普通同步接口几乎没有区别。

03  实习项目不要过度虚假

现在大厂、中厂的面试官，都是一线在职资深开发，天天对接真实业务、处理真实流量问题。

你的项目场景对不对、逻辑通不通、是不是网课模板、是不是编造造假，人家扫一眼三秒钟就能判断出来。

就算全面试，因为你的技术方案是错的，就必然减分。那一个拔尖考试，就肯定会挂。