消息队列面试常见问题,分布式面试题整理
00-1010简介1。面试官：你考虑过如何解决重复留言的问题吗？2.采访者：在多集群消息架构中，如果消费者要求收到的消息是有序的，如何解决顺序消息消费的问题？3.面试官：那不分区的题目怎么做？能举个例子吗？摘要
00-1010我在《项目中为什么要使用消息队列》中列举了两个使用消息队列的例子。
(1)收银系统，确认付款成功，并通过MQ通知物流系统发货。
(2)消费积分，用户每消费一笔都会获得一定的积分。JD.COM豆，信用卡积分，如果2020年电商平台还没有倒闭，可以百分百确定订单系统和积分/奖励系统没有耦合在一起。
这些是使用消息队列的典型场景。
所以问题来了。想象一下，当积分系统收到来自同一用户的同一订单的两条相同消息时会发生什么。会不会分两次加？针对这个问题，面试官又开始了一轮三连问。你还能处理吗？
不是“面试造火箭，工作拧螺丝”，新闻重复，新闻积压是你入职后在工作中真正会遇到的事情，也不是面试官故意刁难你。
目录
00-1010问题分析：我们拿上面的例子来分析一下。当积分系统收到来自同一用户的同一订单的两条相同消息时会发生什么？不考虑两次发消息的原因，会不会分两次加？
产品经理说：那肯定不行。给100分需要100元，但是积分不是用一送一服务买的。
订单RD说：我不能保证分播只发一次。万一出现同样消耗点的bug，很难说消息可能会发几百次。
答：产品说不会，订单RD说他不能保证消息不会重复，卡夫卡架构RD也说不能保证消息不会重复。我该怎么办？我负责积分系统，针对积分累积问题，我会设计* *“幂等”* *界面。对于这个问题，首先我们要对来自上游的消息进行再处理，但是我们不能100%确定上游的系统是可靠的。我是消息消费者，只有在这里设计幂等，才能完全避免这种与金钱有关的bug。毕竟如果靠上游，我们真的是给用户消费100元加10%。
我可以根据用户的订单号或者序列号进行强幂等，用点数记录每一次成功的操作。即使消息过载，我只需要判断同一个订单号已经用积分操作过了，然后我们就不再做任何操作了。
给面试官写了个伪代码：
//如果没有收到给用户的消费通知，先判断这个orderId已经有过积分历史。如果还没有操作过，就会添加。如果已经操作过，直接返回，不做任何处理。ListUserPointHistory lists=userpointdao . query history(orderId)；If(集合utils。不为空(列表)){//1。加100分。userPoint.add(pointCount，orderId)；//2.保存添加的记录user point . add history(orderId)；}else{ log.info(此订单已进行积分运算)返回null}提示：如果还是不懂幂等，可以看我写的《谈谈怎么理解接口幂等设计，项目中如何保证接口幂等》。上述代码应添加点，并以事务方式保存添加的记录。不懂酸，就不要给自己挖坑，被面试官抓住问酸。
面试官：这个问题相对来说比较容易，但是如果你有解决方法的话问题不大。
引言
00-1010问题分析：这个问题是什么意思？例如，如果生产者发送的消息是1 2 3，消费者收到的消息也是1 2 3，这就给工程师造成了困难。但是，还是有办法的。如果要实现消息顺序，就要牺牲一些东西——性能/可靠性。
答：这个问题从三个角度考虑：
生产者：让生产端同步发送消息，确认消息1成功后再发送消息2。它不能是异步的，这样消息才能按顺序排队。
服务器端：生产者-MQ服务器-消费者一对一关系，一对一服务，肯定能保证消息按顺序消费，那么问题来了：
如果生产者-MQ服务器-消费者的任何一个环节出现问题，整个环节都必须被阻断。单通道性能成为瓶颈。主题没有被分区：这意味着相同的主题被放入一个队列中。在分布式环境中，如果同一个主题进入多个分区，那么多个分区之间的消息顺序是无法保证的。
消费者：确保消费者端是串行消费，禁止多线程。
但是这些方法会牺牲系统的性能和稳定性，而且用MQ做顺序问题也不容易。
法了。
3、面试官：
那如何做到topic不分区，能举例说明一下吗？
问题分析：说真的，工作中要求消息顺序消费的业务场景真的挺少见的，用到的时候少，你可以不用深入研究这一块，知道方法就行，到时候真的遇到了知道从哪个方向下手。
答：用当前比较流行的RocketMQ和Kafka举例。
RocketMQ：RocketMQ提供了MessageQueueSelector队列选择机制，我们可以把 Topic 用Hash取模法，相同Topic的Hash值肯定是一样的，让同一个 Topic 同一个队列中，再使用同步发送，这样就能保证消息在一个分区有序了。
Kafka： Kafka可以把 max.in.flight.requests.per.connection 参数设置成1，这样就可以保证同一个topic在同一个分区内了。
Tip：Topic就是一个字符串，给同一类消息取个名字加以区分，如：topic.com.xxx.order.orderId，大多数用户都可以通过message key来定义，因为同一个key的message可以保证只发送到同一个partition，比如说key是user id，table row id等等。
总结
关于消息重复和消息顺序消费问题解决思路比较简单，都是一些小技巧，虽然内容比较枯燥，但是我已经尽力说得通俗易懂。
如果用两句话概括这一接的内容：
如何保证消息重复问题：消费端接口幂等。如何保证消息顺序消费问题：让同一个消息不分区，且单线程。
当然面试的时候你可别这么干巴巴两句话，那显得你太没水平了，面试最理想的效果就是无论多简单的问题你都能滔滔不绝，让面试官无话可说。
以上就是分布式面试消息队列解决消息重复保证消息顺序的详细内容，更多关于消息队列解决消息重复保证消息顺序的资料请关注盛行IT其它相关文章！
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。