亲宝软件园·资讯

展开

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

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 一对一关系,一对一服务,这肯定能保证消息是按照顺序消费的,那么问题来了:

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

总结

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

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

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

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

加载全部内容

相关教程
猜你喜欢
用户评论