文章主要介绍了在架构设计中,MQ(消息队列)如何实现消息幂等性,包括上下半场消息传递的流程和如何实现上下半场消息幂等的问题。文章还提到了消息落地、消息超时、重传和确认等核心设计点。
MQ的消息传递被解耦成上下两个半场:上半场是发送方将消息投递给MQ,下半场是MQ将消息投递给接收方。
在上半场,通过生成全局唯一的inner-msg-id来实现消息去重和幂等。这个id由MQ生成,具备业务无关性。
在下半场,通过业务处理方带入biz-id来实现消息去重和幂等。这个biz-id对业务唯一,业务相关。
业务处理方需要确保biz-id的全局唯一性,并在接收消息时进行判重,以保证消息的幂等性。
但消息重传可能导致reciever收到重复的消息,从而对业务产生影响。MQ如何实现消息幂等呢?这还是得从MQ的消息发送流程说起。1. sender将消息发送给MQ-server;如果步骤3超时,步骤1会重传,会导致步骤2收到重复的消息。此时,消息的收发在MQ系统内闭环,可以由MQ来实施消息幂等。为了避免步骤2落地重复的消息,对每条消息,MQ系统内部必须生成一个inner-msg-id,作为去重和幂等的依据。2. 由MQ生成,具备业务无关性,对消息发送方和消息接收方都透明; 有了这个inner-msg-id,就能保证上半场重发,也只有1条消息落到MQ-server的DB中,实现上半场幂等。5. reciever收到消息,处理业务逻辑,将ACK发送给MQ-server;
6. MQ-server收到ACK,将之前已经落地的消息删除,流程结束;如果步骤5超时,步骤4会重传,会导致业务处理方收到重复的消息。此时,消息的收发不能在MQ系统内闭环,只能由业务处理方来保证消息幂等。在消息实体中,必须有一个biz-id,作为去重和幂等的依据,这个biz-id的特性是:
1. 对于同一个业务场景,全局唯一;
2. 由业务消息发送方生成,业务相关,对MQ透明;
3. 由业务消息接收方负责判重,以保证幂等;
最常见的biz-id有:
1. 订单id,业务方有义务避免重复生成;
2. 支付id,业务方有义务避免重复扣款;
3. 帖子id,业务方有义务避免重复发布;
...
总结
MQ要想实现幂等,上下半场都必须做到幂等。
上半场:
1. MQ-client生成inner-msg-id,保证上半场幂等;
2. inner-msg-id全局唯一,业务无关,由MQ保证;
下半场:
1. 业务发送方带入biz-id,业务接收方去重保证幂等;
2. 这个biz-id对业务唯一,业务相关,对MQ透明。
幂等性,不仅对MQ有要求,对业务上下游也有要求,那些骂MQ无法保证幂等的架构师,其实自己...
https://endgrate.com/blog/ultimate-guide-to-message-queue-design文章比较系统,视频比较直观。
==全文完==
宝藏号,日更。
点赞,转发,在看,感激不尽!