《面试》你须要知道的消息队列基础

__没有最好的 只有适合的

前言

消息队列在互联网技术存储方面使用如此普遍，几乎全部的后端技术面试官都要在消息队列的使用和原理方面对小伙伴们进行360°的刁难。

消息系统的使用场景

你为啥用消息队列？

公司初期业务体量小，因此直接单机直接无压力，可是后面业务体量不断增大，因而采用微服务的设计思想，分布式的部署方式，因此拆分了不少的服务，随着体量的增长以及业务场景愈来愈复杂了，后来调研了不少方案，咱们决定引入消息队列中间件。

消息队列的经典三场景

• 异步 某些复杂的场景下一个流程里面有不少步骤，步骤越多系统响应就越慢；
  例如电商常见的下单系统:
  
  假设每一个步骤的时间都是500ms, 那系统的响应就是1.5s！ 但若是是这样呢?
  
  系统响应就是支付步骤的500ms, 其余步骤都异步执行！
• 削峰 这个好理解，你的系统平时没什么流量，可是老板临时决定搞一个促销。促销时流量忽然涌入，数据库缓存都扛不住了，怎么办？好办，把全部请求都放入消息队列，你仍是按照日常的处理能力消费。系统平稳的度过了促销！
• 解耦 上面下单系统的的三个步骤每一个步骤都当作一个子系统的话。系统每次都要调用三个子系统完成下单操做。也就是说系统与三个子系统耦合在一块儿了。 但若是使用了消息队列呢，下单成功后，发送一个成功消息到消息队列，其余子系统监听这个消息就好了，不须要去调用其余子系统了。

消息队列的缺点

• 系统可用性下降 系统引入的外部依赖越多，越容易挂掉。原本下单系统调用三个系统的接口就行了，如今加了一个MQ，万一MQ挂了咋整，MQ一挂，整套系统崩溃的，你不就完了？这里就必须保证MQ的高可用！
• 系统复杂度提升 加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的状况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。
• 一致性问题 下单成功了，可是子系统失败了，咋整？你这数据就不一致了。 这个实际上是分布式服务自己就存在的一个问题，不单单是消息队列的问题。这就是分布式事务的知识点了！之后再讲

消息队列选型

选择哪一个应该根据你的使用场景，若是一个几万用户的小系统硬上Kafka，可能获取的回报是至关小的。

没有最好的技术，只有最合适的技术!

回见!