面试一线互联网大厂？那这道题目你必须得会！

时间 2019-11-09

标签面试一线互联网大厂题目必须栏目快乐工作繁體版

原文原文链接

欢迎关注我的公众号：石杉的架构笔记（ID:shishan100）程序员

周一至周五早8点半！精品技术文章准时送上！面试

精品学习资料获取通道，参见文末算法

一、面试官为啥要出这样一个开放式问题

这篇文章简单给你们来聊一个互联网大厂的Java面试题：若是让你设计一个消息中间件，你会怎么作？数据库

其实这个问题以前大体给你们聊过，本质就是面试官在考察一个高级以上的Java工程师的系统设计能力。缓存

给你一个平时你们都经常使用的一个消息中间件做为命题，让你现场开放式发挥，立马开动脑筋说说若是让你来设计这么一个消息中间件。性能优化

让你从总体架构，核心流程，数据结构，等各个层面来考虑，你会如何完成这个设计？网络

其实任何一个面试官都应该知道，若是一我的没有真的作过消息中间件开发的话，是不太可能在短期内，瞬间给出一套特别靠谱的架构设计方案的。数据结构

可是用这个题目做为一个开放式命题，他最大的好处，就是能够尽量的挖掘出一个候选人的较为真实的系统设计的能力和功底。架构

为何这么说呢？并发

由于若是面试的时候不少东西都是一些常见的技术问题，好比说：

消息中间件如何保证数据不丢失？
聊聊Elasticsearch的架构原理以及性能优化？
大家公司的微服务架构总体如何设计的？

这些问题相对来讲都是比较固定的一些问题。

所谓固定的问题，就是只要你花费一些时间去学习了相关的技术，或者是在本身所在的公司确实有过一些落地的经验，一般来讲回答出这些问题就不是太大的问题了。

可是这些问题都不够开放，若是两个候选人都一样具有常规问题的回答能力，那么此时经过一道有深度的开放式问题，就能够把几我的里迅速拉开差距，找出来到底谁的技术功底更加深厚，谁的架构设计能力更增强。

那么本文就从各个角度来引导你们去思考一下，假如让你回答这个问题，你能够从哪些方面入手来现场作一些考虑和回答？

二、生产消费模型以及核心数据结构

首先第一个点，消息中间件自己要作的就是能够容许有人来生产消息，还能够容许有人来消费这个消息。

那么这里要考虑的第一个点，就是消息中间件本身自己的核心数据结构。

也就是说，若是有人生产了消息，你做为一个消息中间件，应该如何存储这个数据？

你会存储在内存里呢？仍是存储在磁盘文件里呢？或者二者都同时共存？

能够先容许数据写入内存做为一个缓冲，而后每隔几秒再把数据刷入磁盘文件中？数据刷入磁盘文件以后，这个磁盘文件有多少个？

你总不能一直搞一个磁盘文件来存放全部的数据吧？那么按照什么样的规则对磁盘文件作一个拆分？

数据写入磁盘文件以后，是否是要有相应的一些metadata来标识这个数据的具体信息？好比这个数据的offset偏移量，或者是一个内置的惟一id？

接着如今数据是被存储在磁盘文件里了，那么此时你如何把数据投递到下游的消费者里去呢？

你的消费模型是什么样的？好比说一个queue里的数据，是会均匀分配给消费者的各个实例呢？仍是会怎么作呢？

在这里给你们作一个提示，建议你们能够去研究研究好比kafka底层的文件存储原理，那是很是经典的高性能高并发消息中间件存储架构的实现。

另外就是能够参考一下rabbitmq和kafka的官网，研究一下不一样中间件的消费模型是怎么作的。

三、支撑TB级数据写入的分布式架构

接着你应该考虑第二个大的问题，就是你的消息中间件确定会遇到天天TB级海量数据高并发高吞吐写入的场景。

此时，你的消息中间件的架构如何支撑呢？

因此这里你就要考虑一下，你的数据是否是要分布式的存储？

好比说假如你一天写入几百TB的数据，那不可能都放在一台机器上吧？因此数据的分布式存储是否是你要考虑的另一个很重要的问题？

你是否是要考虑把一个大的数据集合作分片存储，好比说分红N片数据，每一个数据分片放在一台机器上，这样就能够充分利用多台机器的资源来承载TB级的大量数据了。

此外你还须要考虑，你的数据分片是否是要能够支撑扩容？

好比你一开始设置的分片数量是10个，存在10台机器上。结果如今发现10台机器都扛不住了，须要扩容到20个分片，放在20台机器上才能够。

那你是否是要支持数据分片的扩容以及自动数据负载均衡迁移？也就是10个分片的数据自动均匀分配给扩容后的20个分片。

因此这种分布式以及可伸缩的架构，是另一个很是核心的点。

我我的一样比较建议你们研究一下kafka在这块的架构设计，很是的优秀，采用了partition的概念实现数据分片，支持分布式的数据存储，并且还支持动态扩容。

四、数据宕机场景下的高可用架构

你们此时就要考虑另一个问题了，就是一旦数据分布式存储以后，那么每台机器上都有一部分数据。

万一这台机器宕机了呢？那么数据是否是就丢失了？

是的！因此高可用的架构在这里就必须考虑到了。

通常分布式系统实现高可用架构，都是采用多副本冗余机制

也就是说一份数据在多台机器上都搞一个副本，这样任何一台机器宕机了，数据确定不会丢失，你还能够继续使用其余机器上的副本数据来支持生产和消费。

一样建议你们，研究一下kafka的多副本冗余机制，他的每一个partition数据分片都是有多个副本的，任何一台机器宕机，丢失一个数据分片，还有其余机器上的副本分片在，能够支持数据不丢失。

五、支持数据不丢失的ack机制

最后再考虑一个问题，你的消息中间件确定是要支持数据绝对不丢失的吧？

那么你必需要支持生产端和消费端的ack机制，这块内容咱们以前都用多篇文章讲解过里面的具体的原理，你们能够参考一下：

在这里你必须考虑两块ack机制，一个是生产端，一旦投递了消息，必需要求他将数据好比写入多个副本以后，才返回一个ack回调响应。

不然要是一直没收到ack的话，就须要重发一条消息过去，保证生产投递成功。

另一个是消费端，一旦消费处理成功一条消息了，必须返回一个ack给消息中间件，而后消息中间件才能删除这条消息。

不然一旦消费者宕机，就必须重发这条消息给其余的消费者实例，保证消息必定会被处理成功。

这块若是你们不清楚，建议必定重看以前的系列文章，咱们基于rabbitmq来阐述的这个数据不丢失的全链路ack机制。

六、最后的总结

这种开放式面试题，牵扯了大量的底层细节和架构思想，很是区分不一样人的技术水平。若是你往简单了回答，就本文涉及到的一些东西简单说一说，基本也能过关。

可是若是你想技压群雄，就必需要根据本文每一个部分提示的东西，真的去对各类MQ中间件的底层源码进行深刻的研究，而后才能在回答这个问题的时候，展示出“碾压其余人”的技术功底和架构实力。

End

（封面图源网络，侵权删除）

扫描下方二维码，备注：“资料”，获取更多“秘制” 精品学习资料

若有收获，请帮忙转发，您的鼓励是做者最大的动力，谢谢！

一大波微服务、分布式、高并发、高可用的原创系列文章正在路上

欢迎扫描下方二维码，持续关注：

石杉的架构笔记（id:shishan100）

十余年BAT架构经验倾囊相授