【面经】面试官问我:如果让你设计一个高并发的消息中间件,你会怎么做?

简介: 很多小伙伴去大厂面试,几乎都会遇到一些开放式的题目,这些开放式的题目没有固定的答案,但是它能够实实在在的体现面试者较为真实的系统设计能力和技术功底。如果你回答的比较完美,那么,通过这种开放式题目,就能够让你从众多的面试者中脱颖而出。今天,我们就一起来聊聊,去大厂面试时,一个较为常见的开放式题目:如果让你设计一个高并发的消息中间件,你会怎么做?

消息中间件涉及的知识点

要想设计一个具有高并发的消息中间件,那么首先就要了解下消息中间件涉及哪些具体的知识点。通常,设计一个良好的消息中间件需要了解的知识点如下:

  • 生产者消费者模型。
  • 支持分布式架构。
  • 数据的高可用。
  • 消息数据不丢失。

接下来,我们就针对消息中间件来分别谈谈这些技术点。

生产者消费者模型

相信很多小伙伴对于生产者和消费者模型都比较了解了,简单的说:就是消息中间件能够使其他应用来生产消息,也能够使其他应用来消费相应的消息。

对于生产者和消费者模型,我们需要考虑的问题点就比较多了。接下来,我就一步步来引导大家进行思考。

首先,我们来思考这样一个问题:如果生产者生产了消息,那么消息中间件应该怎样存储相应的数据呢?存储在内存? 存储在磁盘?还是同时存储在内存和磁盘中呢?

如果是将消息数据同时存储在内存和磁盘中,我们又该如何处理这些数据呢?是生产者将消息投递到消息中间件之后,我们就立刻将数据写入磁盘?还是说数据先驻留到内存,然后每隔一段时间刷到磁盘上?如果是每隔一段时间刷到磁盘上,那我们又要考虑磁盘文件的切分问题,也就是说,需要将分成多少个磁盘文件?(总不能把所有的数据放到一个磁盘文件中吧)。如果是需要切分成多个磁盘文件,那切分的规则又是什么呢?

上面这些问题都是我们在设计一个消息中间件时需要考虑的问题。然而,这还只是一小部分问题。如果想在面试时脱颖而出,那就还需要继续往下看,还有一些重要的问题点需要注意。

如果文件按照一定的规则切分到多个磁盘文件中了,那是不是还需要一些对于元数据的管理来标识数据的具体消息(就像是Hadoop中的NameNode节点中存储着DataNode的元数据信息,NameNode节点通过这些元数据信息就能够更好的管理DataNode节点)?这些元数据可以包括:消息数据的偏移量、也可以是消息数据的唯一ID。

考虑完数据的存储问题,我们还需要考虑的是:消息中间件是如何将数据投递到对应的消费者的?

在设计生产者和消费者时,还一个很重要的问题需要我们考虑:我们在设计消息中间件时,采用的消费模式是什么?会不会将数据均匀的分配给消费者?还是会通过一些其他的规则将数据投递到消费者?

支持分布式架构

如果你设计的消息中间件,每天会承载TB级别的数据高并发和高吞吐量的写入操作。这里,我们就需要考虑将消息中间件设计成分布式架构。

在设计分布式架构时,我们还需要考虑将要存储的比较大的数据,做分片存储,数据分片等操作。

除了这些,我们还需要考虑另外一个核心问题:对消息中间件,需要支持自动扩容操作。

是否支持数据分片?如何实现数据分片的扩容和自动数据负载均衡迁移?

数据的高可用

一般互联网应用的高可用,是通过本地堆内存,和一份数据在不同的服务器上都搞一个副本。此时,任何一个存储节点宕机。

在现实中,数据的高可用,需要一些理论的支持。

消息数据不丢失

此时,我们就需要提供手动ACK的机制,也就是说:当消费者真正消费消息完毕后,向消息中间件返回“ 处理完成” 的标识。

但是,细化的话,这里,我们就需要两套ACK机制:

  • 一种ACK对应的是生产端。如果一直没有接收到ACK消息,则需要通过生产者重新发送消息
  • 另一种ACK对应的是消费端。一旦消费处理成功一条消息了,必须返回一个ack给消息中间件,然后消息中间件才能删除这条消息。否则一旦消费者宕机,就必须重发这条消息给其他的消费者实例,保证消息一定会被处理成功。

今天,我们没有聊具体的业务点,而是从整体上考虑:如果实现一个消息中间件,需要我们注意的各项知识点和专业技能!好了!

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
缓存 前端开发 中间件
[go 面试] 前端请求到后端API的中间件流程解析
[go 面试] 前端请求到后端API的中间件流程解析
|
10月前
|
算法 NoSQL 应用服务中间件
阿里面试:10WQPS高并发,怎么限流?这份答案让我当场拿了offer
在 Nacos 的配置管理界面或通过 Nacos 的 API,创建一个名为(与配置文件中 dataId 一致)的配置项,用于存储 Sentinel 的流量控制规则。上述规则表示对名为的资源进行流量控制,QPS 阈值为 10。resource:要保护的资源名称。limitApp:来源应用,default表示所有应用。grade:限流阈值类型,1 表示 QPS 限流,0 表示线程数限流。count:限流阈值。strategy:流控模式,0 为直接模式,1 为关联模式,2 为链路模式。
阿里面试:10WQPS高并发,怎么限流?这份答案让我当场拿了offer
|
9月前
|
消息中间件 NoSQL 关系型数据库
去哪面试:1Wtps高并发,MySQL 热点行 问题, 怎么解决?
去哪面试:1Wtps高并发,MySQL 热点行 问题, 怎么解决?
去哪面试:1Wtps高并发,MySQL 热点行 问题, 怎么解决?
|
11月前
|
NoSQL 关系型数据库 MySQL
招行面试:高并发写,为什么不推荐关系数据?
资深架构师尼恩针对高并发场景下为何不推荐使用关系数据库进行数据写入进行了深入剖析。文章详细解释了关系数据库(如MySQL)在高并发写入时的性能瓶颈,包括存储机制和事务特性带来的开销,并对比了NoSQL数据库的优势。通过具体案例和理论分析,尼恩为读者提供了系统化的解答,帮助面试者更好地应对类似问题,提升技术实力。此外,尼恩还分享了多个高并发系统的解决方案及优化技巧,助力开发者在面试中脱颖而出。 文章链接:[原文链接](https://mp.weixin.qq.com/s/PKsa-7eZqXDg3tpgJKCAAw) 更多技术资料和面试宝典可关注【技术自由圈】获取。
|
消息中间件 缓存 监控
go高并发之路——消息中间件kafka
本文介绍了高并发业务中的流量高峰应对措施,重点讲解了Kafka消息中间件的使用,包括常用的Go语言库sarama及其版本问题,以及Kafka的版本选择建议。文中还详细解释了Kafka生产者的四种分区策略:轮询、随机、按Key和指定分区,并提供了相应的代码示例。
351 1
go高并发之路——消息中间件kafka
|
存储 NoSQL 架构师
阿里面试:聊聊 CAP 定理?哪些中间件是AP?为什么?
本文深入探讨了分布式系统中的“不可能三角”——CAP定理,即一致性(C)、可用性(A)和分区容错性(P)三者无法兼得。通过实例分析了不同场景下如何权衡CAP,并介绍了几种典型分布式中间件的CAP策略,强调了理解CAP定理对于架构设计的重要性。
516 4
|
NoSQL 中间件 Java
字节面试:聊聊 CAP 定理?哪些中间件是AP? 哪些是CP? 说说 为什么?
45岁老架构师尼恩在其读者交流群中分享了关于CAP定理的重要面试题及其解析,包括CAP定理的基本概念、CAP三要素之间的关系,以及如何在分布式系统设计中权衡一致性和可用性。文章还详细分析了几种常见中间件(如Redis Cluster、Zookeeper、MongoDB、Cassandra、Eureka、Nacos)的CAP特性,并提供了高端面试技巧,帮助读者在面试中脱颖而出。尼恩还推荐了其团队编写的《尼恩Java面试宝典PDF》等资料,助力求职者准备面试,提升技术水平。
|
缓存 NoSQL 中间件
redis高并发缓存中间件总结!
本文档详细介绍了高并发缓存中间件Redis的原理、高级操作及其在电商架构中的应用。通过阿里云的角度,分析了Redis与架构的关系,并展示了无Redis和使用Redis缓存的架构图。文档还涵盖了Redis的基本特性、应用场景、安装部署步骤、配置文件详解、启动和关闭方法、systemctl管理脚本的生成以及日志警告处理等内容。适合初学者和有一定经验的技术人员参考学习。
793 7
|
缓存 算法 架构师
京东面试:如何设计600Wqps高并发ID?如何解决时钟回拨问题?
资深架构师尼恩在其读者交流群中分享了关于分布式ID系统的设计与实现,特别是针对高并发场景下的解决方案。他强调了分布式ID系统在高并发核心组件中的重要性,并详细介绍了百度的UidGenerator,这是一个基于Snowflake算法改进的Java实现,旨在解决分布式系统中的唯一ID生成问题。UidGenerator通过自定义workerId位数和初始化策略,支持虚拟化环境下的实例自动重启和漂移,其单机QPS可达600万。此外尼恩的技术分享不仅有助于提升面试表现,还能帮助开发者在实际项目中应对高并发挑战。
京东面试:如何设计600Wqps高并发ID?如何解决时钟回拨问题?
|
监控 网络协议 Java
Java面试题:解释Java NIO与BIO的区别,以及NIO的优势和应用场景。如何在高并发应用中实现NIO?
Java面试题:解释Java NIO与BIO的区别,以及NIO的优势和应用场景。如何在高并发应用中实现NIO?
330 0