订阅者视角的消息重复的产生及应对

最新推荐文章于 2023-11-30 13:44:17 发布

古道湫风

最新推荐文章于 2023-11-30 13:44:17 发布

阅读量338

点赞数

分类专栏： java 消息中间件

本文链接：https://blog.csdn.net/yong______heng/article/details/115296029

版权

11 篇文章 0 订阅

订阅专栏

1 篇文章 0 订阅

订阅专栏

消息重复产生主要有两大类原因：

1、消息发送端应用的消息重复发送：

小结：此类问题都是消息中间件成功将消息写入消息存储中后，返回结果时出现问题，因为有重试机制，造成消息重复

解决方法：重试发送消息时，发送同样的信息，通过幂等避免此类问题

2、消息成功到达消息存储中，消息中间件向外投递消息时重复

总结：此类问题是消费者接收消息并处理成功后，消息中间件未能及时更改消息状态所造成的。

解决方法：

1)、通过分布式事务进行解决；成本较高

2)、通过幂等避免

幂等是一个数学概念，常见于抽象代数中，有两个含义

1、在某二元运算下，幂等元素被自己重复运算（或对于函数是为复合）的结果等于自身结果

2、某一元运算为幂等的时，其两次作用在任一元素后会和其作用一次的结果相同。例：高斯符号

例子：

执行一条update sql

update user set age = 18 where user_id = 100;

这个sql无论执行几次user_id 为100 的用户age字段一直都是18，因此这个操作就是幂等的。

下面这条sql

update user set age = age + 1 where user_id = 100;

这个sql每次执行后 age的值都会进行改变，因为这个操作就不是幂等的

因此对消息重复的方法就是，使消费者的处理是一个幂等操作。这种做法降低了消息中间件的整体复杂性，但是也给消费者带来了一定的限制和门槛

在JMS中，消费者对收到的消息进行确认，有以下几种方式：

AUTO_ACKNOWLEDGE：自动确认，当消费者接受到消息后，会自动进行确认。这个确认时，有可能处理还没开始或尚未完成，因此这种确认方式是不可靠的。
CLIENT_ACKNOWLEDGE：消费者自己确认，如果需要确认消息消费成功，需要主动调用Message接口的acknowledge()方法进行确认。
DUPS_OK_ACKNOWLEDGE：在消费者的消息处理函数执行结束后进行确认，一方面保证了消息一定是处理结束后进行确认，另一方面是不需要主动调用acknowledge()方法进行确认

从上面几种方式可以看出，消费者对消息的接收会出现以下两种情况：

at least once （至少一次）也就是消息传递给消费者至少一次，也有可能多次，这种情况类型消息重复发送，采用CLIENT_ACKNOWLEDGE和DUPS_OK_ACKNOWLEDGE这两种方式在处理消息前没有确认的话，有可能会碰见这种情况
at most once （最多一次）当消费者采用AUTO_ACKNOWLEDGE或CLENT_ACKNOWLEDGE方式并在接收消息后就立即确认时会产生的情况，消费者不会再接收到这个消息

关注