消息队列解决消息重复保证消息顺序

时间:2022-05-28 Q.E.D 人气:3

引言

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

（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等等。

总结

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

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

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

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

加载全部内容