阿里mq是否出现问题，阿里三面容易过吗

本内容由系统网小编为大家分享，Windows系统安装教程、办公系统、软件怎么使用、软件使用教程、办公软件攻略等信息。

当面试官面试候选人时,如果发现候选人的简历中写了在项目中使用了 MQ 技术（如 Kafka、RabbitMQ、RocketMQ），基本上有一个问题:使用MQ时,如何确保消息不会丢失100%?

这个问题在实际工作中很常见,它可以检验候选人掌握MQ中级技术的能力,并使他们有区别。 接下来,我们将从这个问题开始讨论你应该具备的基本知识,以及你应该回答的问题的方式,以及扩展面试点。

案例背景

以京东系统为例，用户在购买商品时，通常你选择使用大豆来扣除一部分金额,在这个过程中，交易服务和京都服务通过MQ消息队列进行通信。在下单时，交易服务向MQ邮件队列发送“撤回帐户X100大豆”,而北京豆类服务则在消费者端消费这一订单,实现真正的减少操作.

那么在这一过程中你会遇到什么问题?

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持RBAC动态权限、多个租户、数据权限、工作流程、三方登录、付款、短信、购物中心等。

项目地址: https://gitee.Zhijiantianya/ruoyi-vue-pro 视频教程: https://doc.iocoder.cn/video/

案例分析

要知道，在互联网面试中，引入 MQ 消息中间件最直接的目的是：做系统解耦合流量控制，追其根源还是为了解决互联网系统的高可用和高性能问题。

系统分离:使用MQ消息队列,可以对系统上游和下游环境变化造成的不稳定性进行隔离,例如,无论如何,京北服务的系统需求也在不断变化,事务服务不需要做任何更改,即使 Kyobeo服务失败,主要的贸易过程还可降低北京大豆服务,实现贸易服务与大豆服务的分离,这个系统非常实用。 流量控制:在流量增加的情况下,如第二次杀伤,MQ也可以用于实现流量的“切削峰填谷”功能,可以根据下游加工能力自动调整流量。

然而,MQ的引入,尽管实施了系统脱耦流控制,也带来了其他问题。

介绍了MQ消息中间体实现系统分离,这将影响系统间数据传输的一致性。在分布式系统中，如果两个节点之间有数据同步,这导致了数据的一致性问题。同理，你需要解决的问题是消息制作者和消息消费者之间的消息数据一致性问题(即如何确保消息不会丢失)。

而引入 MQ 消息中间件解决流量控制， 会使消费端处理能力不足从而导致消息积压，这也是你要解决的问题。

因此,你可以看到问题之间经常存在一个循环,面试官会检查你的解决问题思维的一致性和知识体系的掌握程度。

如何回答“如何确保在使用MQ消息队列时不会丢失消息?”的问题?首先,您需要分析其中的一些问题,例如:

如何知道是否有丢失的消息? 哪些链接可能丢失消息? 如何确保消息不会丢失?

候选人在回答时，首先让面试官知道你的分析思维,然后提供解决方案:网络中的数据传输不可靠,为了解决如何不丢失消息的问题,首先,知道哪些链接可能丢失消息,而且我们如何知道消息是否丢失,最终,它是解决办法(而不是直接提出和说自己的解决办法)。正如建筑设计一样,建筑反映了建筑师的思维过程,设计是最终的解决办法。两者缺一不可。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持RBAC动态权限、多个租户、数据权限、工作流程、三方登录、付款、短信、购物中心等。

项目地址:https://gitee.Zhijiantianya/yudao-cloud 视频教程: https://doc.iocoder.cn/video/

首先,我们研究了一个缺失的环节,一个完成从生产到消费的过程的信息,它可以分为三个阶段:消息生产阶段、消息存储阶段和消息消费阶段。

消息生产阶段：从消息被生产出来，然后提交给 MQ 的过程中，只要能正常收到 MQ Broker 的 ack 确认响应，就表示发送成功，所以只要处理好返回值和异常，这个阶段是不会出现消息丢失的。 消息存储阶段:这个阶段通常直接给MQ消息中间人以确保,但您需要理解它的原理,例如,Broker将复制消息以确保至少两个节点同步并返回 ack。 消息消费阶段：消费端从 Broker 上拉取消息，只要消费端在收到消息后，不立即发送消费确认给 Broker，而是等到执行完业务逻辑后，再发送消费确认，也能保证消息的不丢失。

方案看似万无一失，每个阶段确保消息不会丢失,但在分布式系统中，故障不可避免，作为消息生产端，你不能保证MQ已经丢失了你的资料。消费者是否使用了您的资料,所以，本着 Design for Failure 的设计原则，你仍然需要一种机制,检查消息是否丢失。

紧接着，你还可以向面试官阐述怎么进行消息检测？总体方案解决思路为：在消息生产端，给每个发出的消息都指定一个全局唯一 ID，或者附加一个连续递增的版本号，然后在消费端做对应的版本校验。

它将如何具体实施?你可以使用拦截器。在发送消息到生产终点之前,通过拦截器,将消息版本编号插入到消息中(可以通过不断增加的ID生成版本编号,它也可以由分布的全球唯一的ID生成。然后收到消费者的讯息后,然后通过拦截器检测版本号的连续性或消耗状态,其优点是消息检测代码不会进入业务代码。你可以通过做单独的任务来定位丢失的邮件,做进一步的排查。

这里是你需要注意的:如果有多个消息的产生和消息的消费同时结束,通过增加版本数来实现这一点是困难的。由于版本号的独特性不能保证,消息检测只能通过一个全球唯一的ID方案进行.具体实现原则与版本数的乘法一致。

现在你知道哪些步骤(消息存储、消息消耗)可能有问题,并且有一个检测消息丢失的程序,那么你应该给出设计解决方案来防止消息丢失。

在回答“如何确保我不会丢失信息?”之后,面试官通常会问“如何处理信息重复消费的问题?”

例如:在消息消耗过程中,如果发生故障,发送者将通过补偿机制进行重新测试,再测试的过程可能产生重复消息。我们如何解决这个问题?

事实上,这个问题可以由如何解决消费端权力平等问题(权力平等是一个命令,任何多个执行的效应与一个执行的效应相同)的公式来取代,只要消费端有权力平等,那么重复消费者信息的问题就会得到解决。

我们还是来看扣减京豆的例子，将账户 X 的金豆个数扣减 100 个，在这个例子中，我们可以通过改造业务逻辑，让它具备幂等性。

最简单的实现方案，在数据库中建立一个消息日志表,这个表有两个字段:消息ID和消息执行状态。这样，可以更改我们的消费消息的逻辑:将消息记录添加到消息记录表中,然后根据消息记录,异步操作更新用户大豆平衡.

因为我们总是在插入消息之前检查消息是否存在,因此,消息不会重复执行,这样, 实现功率等价的操作.当然，基于这个思路，你不仅可以使用关系数据库,也可以使用Redis而不是数据库来实现限制。

在这里我多说一句，想要解决“消息丢失”和“消息重复消费”的问题，有一个前提条件就是要实现一个全局唯一 ID 生成的技术方案。这也是面试官喜欢考察的问题，你也要掌握。

在分布式系统中，全局唯一 ID 生成的实现方法有数据库自增主键、UUID、Redis，Twitter-Snowflake 算法，我总结了几种方案的特点，你可以参考下。

我提醒你注意，无论哪种方法，如果你想同时满足简单、高可用性和高性能的要求,就要有取舍，所以你必须站在现实生活中,解释一下你选择的平衡点是什么。我个人在业务中比较倾向于选择 Snowflake 算法，该项目也进行了一些修改,主要是为了使算法的ID生成规则与业务特点更加一致,以及优化诸如时钟回拨问题。

当然,除了“如何解决重复新闻消费问题”之外,面试官还会问你“新闻压力”的问题。 原因是,消息加载反映了性能问题,而消息加载问题的解决可以表明,候选人能够在高平行场景中处理消费能力问题。

当你回答这个问题时,你仍然需要向面试官传递一个思考的过程:如果有一个问题,那一定是一个性能问题。如果你想解决从生产到消费的信息的性能问题,首先你需要知道哪些链接可能有问题,然后你需要思考如何解决。

因为只有发送消息后才会发生累积的问题,因此它与消息制作的结局无关,又因为绝大部分的消息队列单节点都能达到每秒钟几万的处理能力，与商业逻辑相比,该性能不会出现在中间人的消息存储器上。毫无疑问，问题必须是消息消费阶段,那么从消费端入手，如何回答呢？

如果出现突然的问题,暂时扩大,增加消费端数,同时降低一些非核心业务。 通过扩张和降级来接受流动,以展示你处理紧急情况的能力。

其次,是检测解决异常问题,如监测、记录等,分析消费端业务逻辑代码是否有问题,优化消费端业务处理逻辑。

最后，如果消费端无法处理,纵向扩展可以为消费者提供并行处理能力,但这里有一个点需要特别注意。即 扩大 消费者 的 情况,必须同步扩展的主题主题的分区数目,确保消费者的数目与分区数目相等。如果消费者个案数目超过分区数目,因为分区是单线消费,因此,这种扩张并不有效。

例如,在卡夫卡中,一个 Topic 可以配置多个 Partition（分区），数据将被写成多个分区,但在消费的时候，卡夫卡规定,分区只能由一个消费者消费。主题的分区数决定了消费能力,所以，通过增加面积,可以提高消费者的加工能力。

至此，我们讲解了 MQ 消息队列的热门问题的解决方案，无论是初中级还是高级研发工程师，本篇文章的内容都是你需要掌握的，你都可以从这几点出发，与面试官进行友好的交流。我来总结一下今天的重点内容。

如何确保消息不会丢失？你要知道一条消息从发送到消费的每个阶段，是否存在丢消息，以及如何监控消息是否丢失，最后才是如何解决问题，方案可以基于“ MQ 的可靠消息投递 ”的方式。 如何确保信息不被重复使用?信息补偿时,信息的重复总是存在,因此如何实现消费者的权力平等是这个问题的检验点。 如何处理消息积压问题？这道题的考点就是如何通过 MQ 实现真正的高性能，回答的思路是，本着解决线上异常为最高优先级，然后通过监控和日志进行排查并优化业务逻辑，最后是扩容消费端和分片的数量。

在回答问题的时候，你需要特别注意的是，让面试官了解到你的思维过程，这种解决问题的能力是面试官更为看中的，比你直接回答一道面试题更有价值。

另外，如果你应聘的部门是基础架构部，那么除了要掌握本讲中的常见问题的主线知识以外，还要掌握消息中间件的其他知识体系，如：

如何选择键入的中间消息? 消息中间的队列模型与发布订阅模型之间有什么区别? 为什么一个消息队列达到高吞吐率? 序列、传输协议和存储管理 … >

XTw.com.Cn系统网专业应用软件下载教程，免费windows10系统,win11,办公软件,OA办公系统,OA软件,办公自动化软件,开源系统,移动办公软件等信息，解决一体化的办公方案。