若是让你写一个消息队列,该如何进行架构设计啊?

面试题

若是让你写一个消息队列，该如何进行架构设计？说一下你的思路。

面试官心理分析

其实聊到这个问题，通常面试官要考察两块：

你有没有对某一个消息队列作过较为深刻的原理的了解，或者从总体了解把握住一个消息队列的架构原理。 看看你的设计能力，给你一个常见的系统，就是消息队列系统，看看你能不能从全局把握一下总体架构设计，给出一些关键点出来。 说实话，问相似问题的时候，大部分人基本都会蒙，由于平时历来没有思考过相似的问题，大多数人就是平时埋头用，历来不去思考背后的一些东西。相似的问题，好比，若是让你来设计一个 Spring 框架你会怎么作？若是让你来设计一个 Dubbo 框架你会怎么作？若是让你来设计一个 MyBatis 框架你会怎么作？

面试题剖析

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

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

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

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

能不能支持数据 0 丢失啊？能够的，参考咱们以前说的那个 kafka 数据零丢失方案。 mq 确定是很复杂的，面试官问你这个问题，实际上是个开放题，他就是看看你有没有从架构角度总体构思和设计的思惟以及能力。确实这个问题能够刷掉一大批人，由于大部分人平时不思考这些东西。

更多优质文章请关注个人微信公众号【java后端技术精选】，回复“1024”和“面试”能够领取优质的视频学习资源