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

面试官心理分析

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

• 你在实际工作中到底有没有真正使用过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对应实现的一个细节，如果感兴趣的小伙伴可以微信搜索【码上遇见你】关注后续的文章更新。