分布式面试消息队列解决消息重复保证消息顺序

引言

我在《项目中为什么要使用消息队列》中列举了两个使用消息队列的例子。

（1）收银系统，确认收款成功，通过MQ通知给物流系统发货。

（2）消费积分，用户每消费一笔给用户增加一定积分，京东豆，信用卡积分，2020年如果还没倒闭的电商平台中，可以100%的确定订单系统和积分/奖励系统不是耦合在一起的。

这些都是很典型的使用消息队列的场景。

那么问题来了，想象一下，积分系统收到同一个用户同一个订单两条相同的消息会怎样？积分会被加两遍吗？针对这个问题，面试官又开始一轮三连问，你还能扛得过去吗？

这不是“面试造火箭，工作拧螺丝”，消息重复，消息积压这类问题是你入职后工作中真真切切会遇到的，不是面试官故意刁难你。

1、面试官：

那你有考虑过消息重复问题怎么解决吗？

问题分析：还是拿上面的例子分析，积分系统收到同一个用户同一个订单两条相同的消息会怎样，先不管因为什么原因消息发了两次，积分会被加两遍吗？

产品经理说： 那肯定不行呀，花100块给100个积分，积分没有买一送一服务。

订单系统RD说： 我这边没办法100%保证积分广播只发一次，万一出个bug同一笔消费积分，消息可能发了几百次也不好说。

答：产品说不行，订单RD说他不保证消息不重复，kafka架构RD也说无法保证消息不重复，那怎么办？我是负责积分系统的，针对消息重复问题，我会针对积分累计接口做**“幂等”**设计，这个问题，首先我们应该从上游就做消息去重处理，但是我们不能100%相信上游系统一定可靠，我是消息消费端，只有我这边做了幂等设计才能完全避免这种和钱相关的bug，毕竟如果依赖上游，真的出了用户消费100元最后加了100w积分，这锅重要还是我们背。

我可以根据用户订单号或者流水号做强幂等，每成功操作一次加积分就记录下来，即使消息重负了，我只要判断同一个订单号已经操作加分了，后续我们就不会再做任何操作了。

随手写了一段伪代码给面试官：

//没收到给用户消费通知,先判断这个orderId时候已经有加过积分的历史记录，如果没有操作过，则增加。如果已经操作过，直接返回不做任何处理。
List<UserPointHistory> lists = userPointDao.queryHistory(orderId);
if(CollectionUtils.isNotEmpty(lists)){
    //1.加100分。
    userPoint.add(pointCount,orderId);
    //2.保存增加记录
      userPoint.addHistory(orderId);
}else{
    log.info("该订单已经操作过积分操作")
    return null;
}

Tip：如果幂等还不明白可以看我写的《谈谈怎么理解接口幂等设计，项目中如何保证接口幂等》，上面的代码加积分和保存增加记录要保证事务性，如果你不知道ACID千万别给自己挖坑，被面试官逮住ACID一顿问。

面试官：这个问题相对不难，有解决思路问题就不大了。

2、面试官：

在多集群消息架构中，如果消费端要求接收到的消息是有序的，怎么解决消息顺序消费问题？

问题分析：这个问题什么意思呢，比如一个消息Producer发送顺序是1 2 3，那Consumer接收到的消息也是 1 2 3 ，这就比较为难工程师了，但是还是有办法的，想要实现消息有序就要牺牲点什么东西 ---- 性能/可靠性。

答：这个问题从三个角度考虑：

Producer：让生产端同步发送消息，消息1确定发送成功后再发送消息2，不能异步，保证消息顺序入队。

服务端：Producer -> MQ Server -> Consumer 一对一关系，一对一服务，这肯定能保证消息是按照顺序消费的，那么问题来了：

• Producer -> MQ Server -> Consumer任意一个环节出现问题，那肯定整个链路都阻塞了。
• 单通道模型性能成为瓶颈。

topic不分区：意思就是让同一个topic主题都入一个队列，在分布式环境下如果同一个topic进入多个分区，那多个分区之间肯定无法保证消息顺序了。

Consumer：保证消费端是串行消费，禁止使用多线程。

但是这些方法都会牺牲掉系统的性能和稳定性，顺序性问题非要使用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等等。

总结

关于消息重复和消息顺序消费问题解决思路比较简单，都是一些小技巧，虽然内容比较枯燥，但是我已经尽力说得通俗易懂。

如果用两句话概括这一接的内容：

如何保证消息重复问题：消费端接口幂等。如何保证消息顺序消费问题：让同一个消息不分区，且单线程。

当然面试的时候你可别这么干巴巴两句话，那显得你太没水平了，面试最理想的效果就是无论多简单的问题你都能滔滔不绝，让面试官无话可说。

以上就是分布式面试消息队列解决消息重复保证消息顺序的详细内容，更多关于消息队列解决消息重复保证消息顺序的资料请关注编程网其它相关文章！