1。为什么面试官会问这样一个开放式的问题？这篇文章只是简单的给大家说说一个互联网大公司的Java面试问题：如果让你设计一个消息中间件，你会怎么做？其实这个问题之前已经和大家大致聊过了。本质是面试官在考察一个高级或以上Java工程师的系统设计能力。我给大家一个大家常用的消息中间件作为一个命题，让你们现场发挥的淋漓尽致，如果让你们设计这样的消息中间件，马上开动脑筋说说。让你从整体架构、核心流程、数据结构等多个层面来考虑，你会如何完成这个设计？其实任何面试者都应该知道，如果一个人没有真正做过消息中间件开发，是不可能在短时间内给出一个特别靠谱的架构设计方案的。但是把这个题目当作一个开放式的命题，他最大的好处就是可以尽可能地挖掘出一个候选人更现实的系统设计能力和基础。你为什么这么说？因为如果很多东西都是面试中常见的技术问题，比如：消息中间件如何保证数据不丢失？谈谈Elasticsearch的架构原理和性能优化？贵公司的微服务架构整体是如何设计的？这些问题都是相对固定的问题。所谓固定题，就是只要你花了一些时间学习过相关技术，或者在你的公司有过一些实践经验，回答这些问题通常问题不大。然而，这些问题还不够开放。如果两个候选人回答常规问题的能力相同，那么此时通过一个深度开放式问题，可以快速拉开几个人的差距，看看谁的功底越深，架构设计越强能力。那么这篇文章就引导大家多角度去思考。如果让你来回答这个问题，你能从哪些方面入手，在现场做出一些思考和回答？2.生产消费模型和核心数据结构首先，消息中间件要做的就是让某人生产一条消息，同时也让某人消费这条消息。所以这里首先要考虑的一点就是消息中间件本身的核心数据结构。也就是说，如果有人生产了一条消息，作为消息中间件，你应该如何存储这个数据呢？你会在内存中存储什么？还是存储在磁盘文件中？还是两者同时？能不能让数据先写入内存作为缓冲区，然后每隔几秒就把数据刷到磁盘文件中？数据刷入磁盘文件后，有多少个磁盘文件？你总不能做一个磁盘文件来存储所有的数据吧？那么使用什么样的规则来分割磁盘文件呢？数据写入磁盘文件后，是否应该有相应的元数据来标识数据的具体信息？比如这个数据的偏移量，或者内置的唯一id？那么既然数据是存储在磁盘文件中的，那么这个时候你如何将数据传递给下游的消费者呢？你的消费模式是什么样的？比如一个queue中的数据会不会均匀分布到每个consumer实例中？或者如何？这里给大家提个醒，建议大家可以研究一下Kafka的底层文件存储原理，比如非常经典的高性能高并发消息中间件存储架构的实现。另外可以参考rabbitmq和kafka的官网，研究不同中间件的消费模型是如何制作的。3、支持TB级数据写入的分布式架构接下来要考虑第二个大问题，就是你的消息中间件每天肯定会遇到TB级海量数据高并发高吞吐写入的场景。此时，你的消息中间件架构如何支持呢？所以这里你要考虑一下你的数据是否应该分布式存储？比如你一天写几百TB的数据，不可能全部放在一台机器上吧？那么数据的分布式存储是不是你要考虑的另一个非常重要的问题呢？是否考虑将一个大的数据集合分片存储，比如将其分成N条数据，每个数据分片放在一台机器上，这样可以充分利用多台机器的资源来承载TB-水平数据？很多数据。另外，你还需要考虑你的数据分片能否支持扩容？比如你一开始设置的分片数量是10，分别存储在10台机器上。结果现在发现10台机器扛不住了，需要扩容到20个shard，可以放在20台机器上。那要不要支持数据分片扩容和自动数据负载均衡迁移？即10个分片的数据自动均匀分布到扩容后的20个分片中。所以这个分布式可扩展的架构是另外一个很核心的点。个人也建议大家研究一下Kafka这方面的架构设计。这很棒。它使用分区的概念实现数据分片，支持分布式数据存储，也支持动态扩展。4、数据宕机场景下的高可用架构。这时候你要考虑另外一个问题，就是数据一旦分布存储起来，每台机器都有一部分数据。如果机器坏了怎么办？那么数据丢失了吗？是的！因此，这里必须考虑高可用架构。分布式系统一般通过采用多副本冗余机制来实现高可用架构，也就是在多台机器上做一个数据副本，这样即使任何一台机器宕机，数据也绝对不会丢失。其他机器上的复制数据可以继续用于支持生产和消费。我也建议你研究一下Kafka的多副本冗余机制。它的每个分区数据片段都有多个副本。如果任何一台机器宕机，一个数据片段就丢失了，其他机器上还有副本。碎片可以支持数据丢失。5.支持不丢数据的ack机制最后再考虑一个问题。您的消息中间件必须支持永不丢失的数据，对吗？这里必须考虑两种ack机制。一是生产端。消息发送后，必须要求将数据写入多份，然后返回ack回调响应。否则如果没有收到ack，则需要重新发送消息，以确保生产交付成功。另一个是消费端。消息处理成功后，必须向消息中间件返回ack，消息中间件才能删除该消息。否则一旦consumer宕机，消息必须重新发送给其他consumer实例，才能保证消息被处理成功。如果您对此不清楚，建议您重新阅读之前的系列文章。我们将基于rabbitmq来讲解全链路不丢数据的ack机制。6.最后的总结这种开放式的面试题涉及到很多底层细节和架构思路，区分了不同人的技术水平。如果你回答的比较简单，把本文涉及的一些东西简单说一下，基本就可以过关了。但要想出众，就必须真正根据本文各部分的提示，对各种MQ中间件的底层源码进行深入研究，才能在回答这个问题时表现出“磨”。压倒别人的技术能力和结构强度。
