《吃透MQ系列，BAT等大厂必问技术面试题

Love The Way You Lie 2022-09-04 03:49 193阅读 0赞

在发布-订阅模型中，存放消息的容器变成了 “主题”，订阅者在接收消息之前需要先 “订阅主题”。最终，每个订阅者都可以收到同一个主题的全量消息。

仔细对比下它和 “队列模式” 的异同：生产者就是发布者，队列就是主题，消费者就是订阅者，无本质区别。唯一的不同点在于：一份消息数据是否可以被多次消费。

## 2.3 小结 ##

最后做个小结，上面两种模型说白了就是：单播和广播的区别。而且，当发布-订阅模型中只有 1 个订阅者时，它和队列模型就一样了，因此在功能上是完全兼容队列模型的。

这也解释了为什么现代主流的 RocketMQ、Kafka 都是直接基于发布-订阅模型实现的？此外，RabbitMQ 中之所以有一个 Exchange 模块？其实也是为了解决消息的投递问题，可以变相实现发布-订阅模型。

包括大家接触到的 “消费组”、“集群消费”、“广播消费” 这些概念，都和上面这两种模型相关，以及在应用层面大家最常见的情形：组间广播、组内单播，也属于此范畴。

所以，先掌握一些共性的理论，对于大家再去学习各个消息中间件的具体实现原理时，其实能更好地抓住本质，分清概念。

# 03 透过模型看 MQ 的应用场景 #

目前，MQ 的应用场景非常多，大家能倒背如流的是：系统解耦、异步通信和流量削峰。除此之外，还有延迟通知、最终一致性保证、顺序消息、流式处理等等。

那到底是先有消息模型，还是先有应用场景呢？答案肯定是：先有应用场景（也就是先有问题），再有消息模型，因为消息模型只是解决方案的抽象而已。

MQ 经过 30 多年的发展，能从最原始的队列模型发展到今天百花齐放的各种消息中间件（平台级的解决方案），我觉得万变不离其宗，还是得益于：消息模型的适配性很广。

我们试着重新理解下消息队列的模型。它其实解决的是：生产者和消费者的通信问题。那它对比 RPC 有什么联系和区别呢？

![image][]

通过对比，能很明显地看出两点差异：

> 1、引入 MQ 后，由之前的一次 RPC 变成了现在的两次 RPC，而且生产者只跟队列耦合，它根本无需知道消费者的存在。
> 
> 2、多了一个中间节点「队列」进行消息转储，相当于将同步变成了异步。

再返过来思考 MQ 的所有应用场景，就不难理解 MQ 为什么适用了？因为这些应用场景无外乎都利用了上面两个特性。

举一个实际例子，比如说电商业务中最常见的「订单支付」场景：在订单支付成功后，需要更新订单状态、更新用户积分、通知商家有新订单、更新推荐系统中的用户画像等等。

![image][image 1]

引入 MQ 后，订单支付现在只需要关注它最重要的流程：更新订单状态即可。其他不重要的事情全部交给 MQ 来通知。这便是 MQ 解决的最核心的问题：系统解耦。

改造前订单系统依赖 3 个外部系统，改造后仅仅依赖 MQ，而且后续业务再扩展（比如：营销系统打算针对支付用户奖励优惠券），也不涉及订单系统的修改，从而保证了核心流程的稳定性，降低了维护成本。

这个改造还带来了另外一个好处：因为 MQ 的引入，更新用户积分、通知商家、更新用户画像这些步骤全部变成了异步执行，能减少订单支付的整体耗时，提升订单系统的吞吐量。这便是 MQ 的另一个典型应用场景：异步通信。

除此以外，由于队列能转储消息，对于超出系统承载能力的场景，可以用 MQ 作为 “漏斗” 进行限流保护，即所谓的流量削峰。我们还可以利用队列本身的顺序性，来满足消息必须按顺序投递的场景；利用队列 + 定时任务来实现消息的延时消费 ……

MQ 其他的应用场景基本类似，都能回归到消息模型的特性上，找到它适用的原因，这里就不一一分析了。总之，就是建议大家多从复杂多变的实践场景再回归到理论层面进行思考和抽象，这样能吃得更透。

# 04 如何设计一个 MQ？ #

了解了上面这些理论知识以及应用场景后，下面我们再一起看下：到底如何设计一个 MQ？

## 4.1 MQ 的雏形 ##

我们还是先从简单版的 MQ 入手，如果只是实现一个很粗糙的 MQ，完全不考虑生产环境的要求，该如何设计呢？

文章开头说过，任何 MQ 无外乎：一发一存一消费，这是 MQ 最核心的功能需求。另外，从技术维度来看 MQ 的通信模型，可以理解成：两次 RPC + 消息转储。

有了这些理解，我相信只要有一定的编程基础，不用 1 个小时就能写出一个 MQ 雏形：

> 1、直接利用成熟的 RPC 框架（Dubbo 或者 Thrift），实现两个接口：发消息和读消息。
> 
> 2、消息放在本地内存中即可，数据结构可以用 JDK 自带的 ArrayBlockingQueue 。

## 4.2 写一个适用于生产环境的 MQ ##

当然，我们的目标绝不止于一个 MQ 雏形，而是希望实现一个可用于生产环境的消息中间件，那难度肯定就不是一个量级了，具体我们该如何下手呢？

**1、先把握这个问题的关键点**

假如我们还是只考虑最基础的功能：发消息、存消息、消费消息（支持发布-订阅模式）。

那在生产环境中，这些基础功能将面临哪些挑战呢？我们能很快想到下面这些：

> 1、高并发场景下，如何保证收发消息的性能？
> 
> 2、如何保证消息服务的高可用和高可靠？
> 
> 3、如何保证服务是可以水平任意扩展的？
> 
> 4、如何保证消息存储也是水平可扩展的？
> 
> 5、各种元数据（比如集群中的各个节点、主题、消费关系等）如何管理，需不需要考虑数据的一致性？

可见，高并发场景下的三高问题在你设计一个 MQ 时都会遇到，「如何满足高性能、高可靠等非功能性需求」才是这个问题的关键所在。

**2、整体设计思路**

先来看下整体架构，会涉及三类角色：

![image][image 2]

另外，将「一发一存一消费」这个核心流程进一步细化后，比较完整的数据流如下：

![image][image 3]

基于上面两个图，我们可以很快明确出 3 类角色的作用，分别如下：

> 1、Broker（服务端）：MQ 中最核心的部分，是 MQ 的服务端，核心逻辑几乎全在这里，它为生产者和消费者提供 RPC 接口，负责消息的存储、备份和删除，以及消费关系的维护等。
> 
> 2、Producer（生产者）：MQ 的客户端之一，调用 Broker 提供的 RPC 接口发送消息。
> 
> 3、Consumer（消费者）：MQ 的另外一个客户端，调用 Broker 提供的 RPC 接口接收消息，同时完成消费确认。

**3、详细设计**

下面，再展开讨论下一些具体的技术难点和可行的解决方案。

**难点1：RPC 通信**

解决的是 Broker 与 Producer 以及 Consumer 之间的通信问题。如果不重复造轮子，直接利用成熟的 RPC 框架 Dubbo 或者 Thrift 实现即可，这样不需要考虑服务注册与发现、负载均衡、通信协议、序列化方式等一系列问题了。

当然，你也可以基于 Netty 来做底层通信，用 Zookeeper、Euraka 等来做注册中心，然后自定义一套新的通信协议（类似 Kafka），也可以基于 AMQP 这种标准化的 MQ 协议来做实现（类似 RabbitMQ）。对比直接用 RPC 框架，这种方案的定制化能力和优化空间更大。

**难点2：高可用设计**

高可用主要涉及两方面：Broker 服务的高可用、存储方案的高可用。可以拆开讨论。

Broker 服务的高可用，只需要保证 Broker 可水平扩展进行集群部署即可，进一步通过服务自动注册与发现、负载均衡、超时重试机制、发送和消费消息时的 ack 机制来保证。

存储方案的高可用有两个思路：1）参考 Kafka 的分区 + 多副本模式，但是需要考虑分布式场景下数据复制和一致性方案（类似 Zab、Raft等协议），并实现自动故障转移；2）还可以用主流的 DB、分布式文件系统、带持久化能力的 KV 系统，它们都有自己的高可用方案。

**难点3：存储设计**

# 最后分享一波我的面试宝典——一线互联网大厂Java核心面试题库 #

**以下是我个人的一些做法，希望可以给各位提供一些帮助：**

> **[点击《一线互联网大厂Java核心面试题库》即可免费领取][Java]**，整理了很长一段时间，拿来复习面试刷题非常合适，其中包括了Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等，且还会持续的更新…可star一下！

![image][image 4]

**283页的Java进阶核心pdf文档**

> Java部分：Java基础，集合，并发，多线程，JVM，设计模式
> 
> 数据结构算法：Java算法，数据结构
> 
> 开源框架部分：Spring，MyBatis，MVC，netty，tomcat
> 
> 分布式部分：架构设计，Redis缓存，Zookeeper，kafka，RabbitMQ，负载均衡等
> 
> 微服务部分：SpringBoot，SpringCloud，Dubbo，Docker

![image][image 5]

**还有源码相关的阅读学习**

![image][image 6]

微服务部分：SpringBoot，SpringCloud，Dubbo，Docker

\[外链图片转存中…(img-K477ZvIw-1628594834271)\]

**还有源码相关的阅读学习**

\[外链图片转存中…(img-dmNsRGLi-1628594834272)\]

[image]: /images/20220829/eb466610115c4559972698561b3d5f82.png
[image 1]: /images/20220829/9de261bf52c2459191f6abc60712f612.png
[image 2]: /images/20220829/2e4902dc4f7f4dcc9b7f25d63b86f307.png
[image 3]: /images/20220829/1bada81e0e9f4cd9aa7d94b7ccd7f01f.png
[Java]: https://gitee.com/vip204888/java-p7
[image 4]: /images/20220829/0005244de6294c2488c19898576e2b37.png
[image 5]: /images/20220829/f7e30e82110844da859c0e42ab6f2b95.png
[image 6]: /images/20220829/1ffbc093ceb0486cba2d654ac98656ca.png