15如何解决消息重复，保证消息顺序问题

自信和希望是青年的特权。——大仲马

引言

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

（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 ，这就比较为难工程师了，但是还是有办法的，想要实现消息有序就要牺牲点什么东西 —- 性能/可靠性。

我：

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

1. Producer：让生产端同步发送消息，消息1确定发送成功后再发送消息2，不能异步，保证消息顺序入队。
2. 服务端：Producer -> MQ Server -> Consumer 一对一关系，一对一服务，这肯定能保证消息是按照顺序消费的，那么问题来了：
   1. Producer -> MQ Server -> Consumer任意一个环节出现问题，那肯定整个链路都阻塞了。
   2. 单通道模型性能成为瓶颈。
3. topic不分区：意思就是让同一个topic主题都入一个队列，在分布式环境下如果同一个topic进入多个分区，那多个分区之间肯定无法保证消息顺序了。
4. 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等等。

总结

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

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

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

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