作为一名java程序员，求职面试时，时常会遇到一些开放性题目。

张工是一名java程序员，最近到某知名互联网公司面试，面试官就提了这样一个问题：

我看你简历上写着熟悉kafka，如果让你自己写一个消息队列，该如何进行架构设计？简单说说一下你的设计思路。

张工被面试官这么一问，有点不知所措。

其实面试官问这个问题无非就是考察两点：

既然简历上写着熟悉kafka，正好考察你对kafka消息中间件有没有做过较为深入的原理的了解，或者从整体了解把握住一个消息队列的架构原理；

考察你的设计能力，能否从全局把握一下整体架构设计，给出一些关键点出来。

面试时，遇到类似这样的开放性题目，相信不少人会有点懵，因为平时就没有思考过类似的问题，突然来这么一问，有点出乎意料。

类似的问题，比如，如果让你来设计一个图片加载框架你会怎么做？

我在面试一位Android求职者时，问了这样一个问题：

“请问你加载网络图片是用第三方框架还是自己写的？”

“用第三方框架”

“用哪个？”

“Glide”

“Picasso,Fresco这些框架也挺不错的，为何选择Glide呢？能否简单说说，比如性能方面？”

“这个，没有研究过，我们项目中用的就是这个”

“那有没有和其他框架对一下简单的对比才选择Glide”

“没有”回答得挺干脆的。

其实我的初衷是想知他有没有用glide和其他的框架做一下对比。我总觉得选择总得有理由，有自己的思考，而不是别人怎样就怎样，总跟着别人的节奏走。

无论是工作还是学习，我们在平时使用一些框架时，尽量要有自己的思考。譬如消息中间件有RabbitMQ、Kafka、ActiveMQ。当我们选择Kafka作为我们项目的消息队列处理，应该有选择的理由。

回答这类问题，不求你深入研究过其源码，但起码我们要知道个大概，知道其基本原理、核心组成部分、基本架构构成，然后参照一些开源的框架把一个系统设计出来的思路简单阐述下就好。

比如说这个消息队列系统，我们从以下这个角度来考虑一下：

我们知道，Kafka是一种高吞吐量的分布式发布订阅消息系统，其高吞吐量非常惊人，惊人到什么程度，即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。

我们可以参照一下 kafka 的设计理念，broker -> topic -> partition，每个 partition 放一个机器，就存一部分数据。

要是遇到资源不够了，那也不要紧，给 topic 增加 partition，然后做数据迁移，增加机器，不就可以存放更多数据，这样就可以提供更高的吞吐量了。

其次还得需要考虑一下这个 mq 的数据如何落地磁盘，不落磁盘，数据丢了，去哪里找。

那落磁盘的时候怎么落？沿着这样的思路去思考，就能大致说出个所以然来。

消息队列这玩意是相当复杂的，面试官提问这样的问题，更多是想了解求职者在平时使用中有没有自己的思考，还是只是为了用而用。

总结：

求职面试时，如果不是面架构或技术专家之类的，建议不要出现精通等字样，使用过但不经常用建议写了解，经常使用但没有深入了解的写熟练就好了。

以上五点纯粹是个人经验看法。由于笔者水平有限，文中纰漏之处在所难免，权当抛砖引玉，不妥之处，请大家批评指正。

-END-

作者：洪生鹏  技术交流、媒体合作、品牌宣传请加作者微信: hsp-88ios

猜你喜欢

面试官：分库分表后，id主键如何处理？

一位工作8年程序员的成长感悟，值得深思

更多惊喜，请长按二维码识别关注

你若喜欢，别忘了点【在看】