作者个人研发在高并发场景下提供了一个简单、稳定、可扩展的延迟消息队列框架，具有精准的定时任务和延迟队列处理功能。开源半年多以来，已成功为十几家中小企业提供精准定时调度解决方案，经受住了生产环境的考验。为了造福更多的童鞋，这里给出开源框架的地址：https://github.com/sunshinelyz/mykit-delay前面写了很多小伙伴去大厂面试，几乎都会遇到一些悬而未决的问题。此类问题没有固定答案，但能真实反映出面试者相对真实的系统设计能力和技术水平。如果你回答得很完美，那么，通过这个开放式问题，你就能从一众面试官中脱颖而出。今天，我们一起来聊聊。去大厂面试的时候，一个比较常见的开放式问题：如果让你设计一个高并发的消息中间件，你会怎么做？需要对消息中间件涉及的知识点进行设计。对于高并发的消息中间件，首先要了解消息中间件具体涉及到哪些知识点。通常，设计一个好的消息中间件至少需要满足以下条件：生产者和消费者模型。支持分布式架构。数据的高可用性。消息数据不会丢失。下面针对消息中间件分别说说这几个技术点。生产者消费者模型相信很多朋友对生产者和消费者模型都比较了解。简单的说：消息中间件使其他应用程序能够生产消息，也使其他应用程序能够消费相应的消息。对于生产者和消费者模型，我们需要考虑更多的问题。接下来，我将一步步引导大家思考。首先我们来思考这样一个问题：如果生产者生产消息，那么消息中间件应该如何存储相应的数据呢？存储在内存中？存储在磁盘中？还是同时存入内存和磁盘？如果消息数据同时存储在内存和磁盘中。我们应该如何处理这些数据？生产者把消息投递到消息中间件后，我们马上把数据写入磁盘？还是数据先驻留在内存中，然后隔一段时间再Flash到磁盘？如果是每隔一段时间，那我们就要考虑磁盘文件的切分问题，也就是我们需要把消息数据分成多少个磁盘文件？数据存入磁盘文件）。如果需要拆分成多个磁盘文件，拆分的规则是什么？以上问题都是我们在设计消息中间件时需要考虑的问题。然而，这只是问题的一小部分。想要在面试中脱颖而出，还需要继续往下看，还有一些重点需要注意。如果文件按照一定的规则分成多个磁盘文件，是否还需要管理元数据来标识数据的具体信息（像Hadoop中的NameNode节点存储DataNode的元数据信息，NameNode节点通过这些元数据信息，可以更好的管理DataNode节点）？这些元数据可以包括：消息数据的偏移量，或者消息数据的唯一ID。考虑完数据存储的问题，我们还需要考虑：消息中间件如何将数据传递给相应的消费者？在设计生产者和消费者的时候，还有一个很重要的问题需要我们考虑：我们在设计消息中间件的时候，采用的是什么消费模式？数据会平均分配给消费者吗？还是会通过其他一些规则将数据传递给消费者？如果我们支持分布式架构，如果我们设计消息中间件，每天承载TB级的数据，高并发，高吞吐的写操作。在这里，我们需要考虑将消息中间件设计为分布式架构。在设计分布式架构时，我们还需要考虑将比较大的数据存储在分片中，并对数据进行分片等操作。除了这些，我们还需要考虑另一个核心问题：对于消息中间件来说，需要支持自动扩容操作。还有是否支持数据分片，如何实现数据分片的扩展和数据负载均衡的自动迁移。数据高可用一般互联网应用的高可用是通过本地堆内存、分布式缓存、一份数据在不同服务器上的副本来实现的。此时，任何一个存储节点宕机，都不会影响整体的高可用。我们在设计消息中间件的时候也可以参考这个思路。如果消息数据没有丢失，我们需要提供一个手动的ACK机制。也就是说，消费者消费完消息后，会返回“处理完成”标志给消息中间件，消息中间件会删除对应的处理完的消息。信息。不过具体来说，这里我们需要两套ACK机制：一套ACK对应生产端。如果还没有收到ACK消息，生产者需要重新发送消息以保证消息生产成功。另一种ACK对应的是消费者端。一条消息被消费处理成功后，必须返回一个ack给消息中间件，消息中间件才能删除这条消息。否则一旦consumer宕机，消息必须重新发送给其他consumer实例，才能保证消息被处理成功。今天我们不谈具体的业务点，而是从全局的角度考虑：如果我们实现一个消息中间件，需要注意各种知识点和专业技能！好了，今天就到这里吧。本文转载自微信公众号“冰河科技”，可通过以下二维码关注。转载本文请联系冰川科技公众号。
