下面就是我们帮你搜集整理的有关面试官：如何保证RocketMQ/R和阿里面试：说说你项目里使用的 MQ 的解答
本文目录一览
面试官：如何保证RocketMQ/RabbitMQ消息数据100%不丢失
在分布式系统的网络中,保证消息的可靠性？阿里技术分享了一篇文章：RocketMQ如何保证消息的可靠性？在文中详情介绍了RocketMQ是如何最大限度的保证消息不丢失的呢？分析的思路就是一条消息从产生到最终消费的整个过程，在三个关键的阶段去控制消息的可靠性。
下面分享证RabbitMQ如何保证消息的可靠性，对比去看，一定会有收获~
正在学RabbitMQ，特此记录一下，这里就不讲RabbitMQ基础了，直接进入主题。我们都知道，消息从生产端到消费端消费要经过3个步骤：
这3个步骤中的每一步都有可能导致消息丢失，消息丢失不可怕，可怕的是丢失了我们还不知道，所以要有一些措施来保证系统的可靠性。这里的可靠并不是一定就100%不丢失了，磁盘损坏，机房爆炸等等都能导致数据丢失，当然这种都是极小概率发生，能做到99.999999%消息不丢失，就是可靠的了。下面来具体分析一下问题以及解决方案。
生产端可靠性投递，即生产端要确保将消息正确投递到RabbitMQ中。生产端投递的消息丢失的原因有很多，比如消息在网络传输的过程中发生网络故障消息丢失，或者消息投递到RabbitMQ时RabbitMQ挂了，那消息也可能丢失，而我们根本不知道发生了什么。针对以上情况，RabbitMQ本身提供了一些机制。
事务消息机制由于会严重降低性能，所以一般不采用这种方法，我就不介绍了，而采用另一种轻量级的解决方案——confirm消息确认机制。
什么是confirm消息确认机制？顾名思义，就是生产端投递的消息一旦投递到RabbitMQ后，RabbitMQ就会发送一个确认消息给生产端，让生产端知道我已经收到消息了，否则这条消息就可能已经丢失了，需要生产端重新发送消息了。
通过下面这句代码来开启确认模式：
然后异步监听确认和未确认的消息：
这样就可以让生产端感知到消息是否投递到RabbitMQ中了，当然这样还不够，稍后我会说一下极端情况。
那消息持久化呢？我们知道，RabbitMQ收到消息后将这个消息暂时存在了内存中，那这就会有个问题，如果RabbitMQ挂了，那重启后数据就丢失了，所以相关的数据应该持久化到硬盘中，这样就算RabbitMQ重启后也可以到硬盘中取数据恢复。那如何持久化呢？
message消息到达RabbitMQ后先是到exchange交换机中，然后路由给queue队列，最后发送给消费端。
所有需要给exchange、queue和message都进行持久化：
exchange持久化：
queue持久化：
message持久化：
这样，如果RabbitMQ收到消息后挂了，重启后会自行恢复消息。
到此，RabbitMQ提供的几种机制都介绍完了，但这样还不足以保证消息可靠性投递RabbitMQ中，上面我也提到了会有极端情况，比如RabbitMQ收到消息还没来得及将消息持久化到硬盘时，RabbitMQ挂了，这样消息还是丢失了，或者RabbitMQ在发送确认消息给生产端的过程中，由于网络故障而导致生产端没有收到确认消息，这样生产端就不知道RabbitMQ到底有没有收到消息，就不好做接下来的处理。
所以除了RabbitMQ提供的一些机制外，我们自己也要做一些消息补偿机制，以应对一些极端情况。接下来我就介绍其中的一种解决方案——消息入库。
消息入库 消息入库，顾名思义就是将要发送的消息保存到数据库中。
首先发送消息前先将消息保存到数据库中，有一个状态字段status=0，表示生产端将消息发送给了RabbitMQ但还没收到确认；在生产端收到确认后将status设为1，表示RabbitMQ已收到消息。这里有可能会出现上面说的两种情况，所以生产端这边开一个定时器，定时检索消息表，将status=0并且超过固定时间后（可能消息刚发出去还没来得及确认这边定时器刚好检索到这条status=0的消息，所以给个时间）还没收到确认的消息取出重发（第二种情况下这里会造成消息重复，消费者端要做幂等性），可能重发还会失败，所以可以做一个最大重发次数，超过就做另外的处理。
这样消息就可以可靠性投递到RabbitMQ中了，而生产端也可以感知到了。
既然已经可以让生产端100%可靠性投递到RabbitMQ了，那接下来就改看看消费端的了，如何让消费端不丢失消息。
默认情况下，以下3种情况会导致消息丢失：
其实，上述3中情况导致消息丢失归根结底是因为RabbitMQ的自动ack机制，即默认RabbitMQ在消息发出后就立即将这条消息删除，而不管消费端是否接收到，是否处理完，导致消费端消息丢失时RabbitMQ自己又没有这条消息了。
所以就需要将自动ack机制改为手动ack机制。
消费端手动确认消息：
这样，当autoAck参数置为false，对于RabbitMQ服务端而言，队列中的消息分成了两个部分：一部分是等待投递给消费端的消息；一部分是已经投递给消费端，但是还没有收到消费端确认信号的消息。如果RabbitMQ一直没有收到消费端的确认信号，并且消费此消息的消费端已经断开连接或宕机（RabbitMQ会自己感知到），则RabbitMQ会安排该消息重新进入队列（放在队列头部），等待投递给下一个消费者，当然也有能还是原来的那个消费端，当然消费端也需要确保幂等性。
好了，到此从生产端到RabbitMQ再到消费端的全链路，就可以保证数据的不丢失。
由于个人水平有限，有些地方可能理解错了或理解不到位的，请大家多多指出！Thanks
以上 RabbitMQ 原文链接 :htts://blog.csdn.net/hsz2568952354/article/details/86559470
最后分享一个梳理的消息中间件的思维导图，和面试题。
如需高清思维导图和面试题，关注私信获取。
阿里面试：说说你项目里使用的 MQ ，分布式系统中 MQ 作用？
在阿里的面试中，面试官问到关于 MQ 的几个问题：我之前写过一篇关于 rocketMQ 实现分布式锁的文章，主要介绍如何使用 RocketMQ 实现分布式锁，
《Springcloud + RocketMQ 解决分布式事务》
但是这个功能并不是 MQ 基本功能，也不是所有 MQ 都有的功能。
MQ 在系统中到底有哪些作用呢？抛开基本的消息发布订阅不说，还有以下几点：
在分布式系统中，要么是通过 rest 调用，要么是通过 dubbo 等 RPC 调用，但是有些场景需要解耦设计，不能直接调用。
比如消息驱动的系统中，消息发送者完成本地业务，发送消息，多平台的消息消费者服务需要收到推送的消息，然后继续处理其他业务。
看这两个架构图，第一种 BC 都直接依赖 A 服务，那么如果 A 中的接口修改，BC 都要跟着做修改，耦合度高。
第二种，通过 MQ 来作为中间件收发消息，BC 只依赖收到的消息而不是具体的接口，这样即使 A 服务修改或者增加其他服务，都只要订阅MQ就行。
用户注册业务流程为例，
原来的系统设计，这样的服务流程会串行处理，即先 1-2-3 ；但是这里可以思考下，如果单个服务单台机器的情况下，注册用户特别多，系统能不能抗住？
这里假设各个阶段的时间 1 = 50ms ， 2 = 50ms ， 3 = 50ms，那么一个请求下来就是 all = 150ms；
这里再假设，这个服务器 CPU = 1 ， 且只能处理单线程，那么以这种单台服务器单线程的 QPS 来算；QPS = 1000/150 ≈ 7
现在我要让这个 QPS * 3 提升三倍，这个时候引入 MQ 服务作为中间件
如图可见，我在 A 服务用户注册完成后，就直接返回了，这个时候 MQ 用来发送异步处理消息，B，C 服务分别处理。
A 不用等待 B、C 的返回结果 ，这样用户体验就是只有 50ms 等待时间。而在邮件、短信这个阶段，因为网络延迟原因，
用户可以接受一定时间的等待。
一般的服务，我们的请求访问到系统都是直接请求，这样的模式在用户访问量不大的情况下，问题不是很大。
但是如果用户请求达到了一定的瓶颈或者产生了一些问题，我们就需要考虑优化我们的架构设计，MQ 中间件正是解决办法之一。
下面以秒杀系统为例分析问题
秒杀系统瞬间百万并发，怎么处理？一般秒杀系统会进行请求过滤，无效、重复都会被过滤一遍，剩下的才真正进入到秒杀服务、订单服务。
但即使这样并发仍然很高，如果网关把全部请求都转发到下游订单服务，一样会压垮下游系统，造成服务不可用甚至雪崩。
真实的秒杀系统更复杂 ，包含 Nginx 、网关、注册中心、redis 缓存、mysql 集群、消息队列集群
解决方式就是将上游处理的较快的任务，加入到队列处理，下游逐一消费队列，直到所有队列消费完成。
假如秒杀服务处理请求数：1000/s，
下游订单服务处理请求书：10/s，
为了不给下游订单服务造成压力，秒杀后的信息发送到队列，订单服务就可以从容淡定的每秒处理十个，而不是直接塞 1000 个请求
也不管人家愿意不愿意。
到这里，可以总结下秒杀系统的过滤方式：
所有服务都将日志发送到 MQ 服务用来作为日志存储。
MQ 作为中间件对日志进行持久化、转发
大数据服务对 MQ 读取和进行日志分析
有人上来就是一通性能比较，然后说 RabbitMQ 是世界上最好的 MQ...
你把挑选 MQ 比作挑老婆吧，上来就要全套，肤白貌美、 、性感 、勤劳能干。。。
真是缺乏社会的 啊，兄弟
养得起吗？动不动一套保养套餐，1W/月
守得住吗？隔壁老王经常来你家吃饭吧，疯狂脑补。。。
吃的消吗？红枣+枸杞+肾宝片，怕是心有余力不足吧
言归正传，其实我觉得这是一个思考题，首先我们要看的应该是条件是哪些？
上图的例子日志消息就是使用的 kafka，为什么是kafka？
Kafka是LinkedIn开源的分布式发布-订阅消息系统，属于 Apache 顶级项目，社区活跃。
Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。
后来版本开始支持 ，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。
但是 kafka 相对来说很重，需要依赖 zookeeper，大公司里使用没问题，也少不了专人维护。
RocketMQ 是阿里开源的一套可靠消息系统，已经捐赠 Apache 成为顶级项目。刚开始定位于非日志的可靠消息传输，其实在日志处理方面性能也不错。
目前支持的客户端包括 java，c++，GO ，社区比较活跃，文档还算全面。但是涉及到核心的要修改还是有难度的，毕竟阿里云靠卖这个服务赚钱呢。
所以如果公司实力不自信还是慎重选择吧，实在不行可以直接购买云服务，省心省力，还是那句话，看实际情况。
下图是来源网络的图片，部分描述已经过时，但是基本不差，仅供参考：
这里简单说说，后面专门针对这个问题进行书写招供。
大致就是一些特殊原因例如网络原因，服务重启造成消息消费未被记录，造成重复消费的可能。
一般的处理方式就是保证接口设计的幂等性，主旨通过唯一标识判断是否存在。
总结：以上就是本站针对你的问题搜集整理的答案，希望对你有所帮助。