消息中间件的使用，有效地帮助业务系统进行了异步解耦和削峰，然而也带来了一个新的问题：超时重试的情况下，中间件或者下游业务方会收到重复的消息，如果幂等处理不完善，都有可能会对业务产生影响。
如下图：
msg处理流程
超时情况下，msg-publisher的send（下文统称stepA）和msg-server的send（下文统称stepB）都会因此重发而产生上述问题。
其中stepA的这种情况，无论是蚂蚁dms，阿里RocketMQ，Kafka等消息中间件都会产生一个全局唯一的messgeId从而进行幂等控制以及异常定位；
对于使用方来说，我们需要关注的是stepB,在msg-sub(消息消费方)超时的情况下，消息中间件会进行消息重推，这个时候会导致同一条消息消费重复。
通常的做法是，我们在消息体里面放置一个我们业务系统唯一的业务序列号（以我们部门为例，我们基于twitter的snowflake+我们自己的业务标识来生成系统唯一的业务编号，有兴趣的话，在后续的文章里面我会对此进行代码和设计思路展示），消费方获取消息之后，以此业务号码进行幂等性检验，从而避免业务处理异常。
转载请注明出处。
| 留言与评论（共有 0 条评论） |
