场景题 - 如果让你写一个消息队列，该如何进行架构设计啊？说一下你的思路。

面试官心理分析

首先聊到这个问题，其实主要是想要考察两个点：

• 你在实际工作中到底有没有真正使用过 MQ，并对消息队列原理做过深入的了解。或者是否从整体上是否了解过 MQ 的架构原理。

• 还想从侧面考察你是否拥有一个设计能力，给你一个常见的系统，看你是不是有一个架构思维，能不能全局把控一下整体的涉及。把握住一些关键的点。

其实从候选人的角度来看这个问题，大部分人一上来可能回懵逼的状态。平常很少涉及这个问题，一般平时只要知道怎么使用，了解一些其中比较重要的原理。根本很少去从全局的角度去考虑这个问题，想一些它背后的东西。类似这样的问题其实有很多，比如：如果让你设计一个 Spring 框架你会怎么做，让你涉及一个 Dubbo RPC 远程调用框架你怎么设计？让你设计一个 MyBatis 框架你会怎么去设计？这样的问题其实核心的点也不要你完全看过它核心的源码。只要你大致知道实现它的技术原理、核心技术组成、以及一些关键问题的解决思路是如何的。按着这种方式把链路串起来回答就好。

步入正题

回答这个问题，大致可以从两方面来考虑：

• 首先这个MQ需要支持可伸缩性，就是需要的时候可以快速扩容，这样能够更好的响应访问量激增，从而有一个更好的吞吐量和容量。要想达到这个需求，就需要设计一个分布式的系统，，可以参考 Kafka 的设计理念：broker -> topic -> partition。每个partition放一个机器，就存放一部分数据。如果现在资源不够了，很简单，给 topic 增加 partition，然后做数据迁移，增加机器，就可以提高的吞吐量了。

• 接下来需要考虑的是MQ数据的持久化，通俗一点讲就是把数据落盘，只有将 MQ 的数据持久化下来才能够保证 MQ 进程挂了数据不会丢失。同时还要考虑到落盘的方式：要采用顺序写，这样才会没有磁盘随机读写的寻址开销的性能问题。顺序写同时也是 Kafka 的思路。

• 还需要考虑到 MQ 的可用性。其实这里可以借鉴 Kafka 的高可用保障机制。多副本 -> leader & follower -> brokerbroker 挂了重新选举 leader 即可对外重新服务。

• 还需要考虑到数据的 0 丢失方案：这里我们同样可以参考 Kafka 的数据零丢失方案。

通过以上几点我们就已经对设计一个自己的 MQ 有了一套比较简单系统化的方案。当然上述有很多设计的点是借鉴了 Kafka 的。具体 Kafka 对应实现的一个细节，如果感兴趣的小伙伴可以微信搜索【码上遇见你】关注后续的文章更新。

如有问题，欢迎加微信交流：w714771310，备注- 技术交流 。或关注微信公众号【码上遇见你】。