JAVA面试题分享一百五十五：怎么设计一个MQ？

一、背景

其实回答这类问题，说白了，起码不求你看过那技术的源码，起码你大概知道那个技术的基本原理，核心组成部分，基本架构构成，然后参照一些开源的技术把一个系统设计出来的思路说一下就好；比如说这个消息队列系统，我们来从以下几个角度来考虑一下

（1）首先这个mq得支持可伸缩性吧，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计个分布式的系统呗，参照一下kafka的设计理念，broker -> topic -> partition，每个partition放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给topic增加partition，然后做数据迁移，增加机器，不就可以存放更多数据，提供更高的吞吐量了？

（2）其次你得考虑一下这个mq的数据要不要落地磁盘吧？那肯定要了，落磁盘，才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是kafka的思路。

（3）其次你考虑一下你的mq的可用性啊？这个事儿，具体参考我们之前可用性那个环节讲解的kafka的高可用保障机制。多副本 -> leader & follower -> broker挂了重新选举leader即可对外服务。

（4）能不能支持数据0丢失啊？可以的，参考那个kafka数据零丢失方案

其实一个mq肯定是很复杂的，其实这是个开放题，就是看看你有没有从架构角度整体构思和设计的思维以及能力。

二、MQ 的雏形

1、前言

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

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

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

（1）、直接利用成熟的 RPC 框架（Dubbo 或者 Thrift），实现两个接口：发消息和读消息。

（2）、消息放在本地内存中即可，数据结构可以用 JDK 自带的 ArrayBlockingQueue 。

2、适用于生产环境的 MQ

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

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

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

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

高并发场景下，如何保证收发消息的性能？

如何保证消息服务的高可用和高可靠？

如何保证服务是可以水平任意扩展的？

如何保证消息存储也是水平可扩展的？

各种元数据（比如集群中的各个节点、主题、消费关系等）如何管理，需不需要考虑数据的一致性？

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

2）、整体设计思路

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

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

基于上面两个图，我们可以很快明确出 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：存储设计

消息的存储方案是 MQ 的核心部分，可靠性保证已经在高可用设计中谈过了，可靠性要求不高的话直接用内存或者分布式缓存也可以。这里重点说一下存储的高性能如何保证？这个问题的决定因素在于存储结构的设计。

目前主流的方案是：追加写日志文件（数据部分） + 索引文件的方式（很多主流的开源 MQ 都是这种方式），索引设计上可以考虑稠密索引或者稀疏索引，查找消息可以利用跳转表、二份查找等，还可以通过操作系统的页缓存、零拷贝等技术来提升磁盘文件的读写性能。

如果不追求很高的性能，也可以考虑现成的分布式文件系统、KV 存储或者数据库方案。

难点4：消费关系管理

为了支持发布-订阅的广播模式，Broker 需要知道每个主题都有哪些 Consumer 订阅了，基于这个关系进行消息投递。

由于 Broker 是集群部署的，所以消费关系通常维护在公共存储上，可以基于 Zookeeper、Apollo 等配置中心来管理以及进行变更通知。

难点5：高性能设计

存储的高性能前面已经谈过了，当然还可以从其他方面进一步优化性能。

比如 Reactor 网络 IO 模型、业务线程池的设计、生产端的批量发送、Broker 端的异步刷盘、消费端的批量拉取等等。

三、小结

再总结下，要回答好：如何设计一个 MQ？

1、需要从功能性需求（收发消息）和非功能性需求（高性能、高可用、高扩展等）两方面入手。

2、功能性需求不是重点，能覆盖 MQ 最基础的功能即可，至于延时消息、事务消息、重试队列等高级特性只是锦上添花的东西。

3、最核心的是：能结合功能性需求，理清楚整体的数据流，然后顺着这个思路去考虑非功能性的诉求如何满足，这才是技术难点所在。