RocketMQ 集群核心概念-幂等消息-幂等问题的出现

幂等消息-幂等问题的出现

幂等性：多次操作造成的结果是⼀致的。对于⾮幂等的操作，幂等性如何保证？

1）在请求⽅式中的幂等性的体现

get：多次get 结果是⼀致的

post：添加，⾮幂等

put：修改：幂等，根据id修改

delete：根据id删除，幂等

⽣产者重复发送：由于⽹络抖动，导致⽣产者没有收到broker的ack⽽再次重发消息，实际上broker收到了多条重复的消息，造成消息重复。

生产者将消息发送做的是同步发送，那就意味着生产者得等待broker返回ack才可以做下面的动作。

现在由于网络的抖动导致生产者这条消息发送之后没有办法收到broker的ack，那么生产者根据之前的机制的设定还会再次去发送，那么这条消息按照正常的链路来走的话就是被消费者消费两次。

消息队列应用的逻辑一直是在做增删改，而不是做查询，那么发送了两条消息意味着消费者会把两条数据都添加到数据库。

这样由于生产者没有收到ack导致非幂等的操作就出现了。这是生产者出现非幂等的情况。

消费者重复消费：由于⽹络抖动，消费者没有返回ack给broker，导致消费者重试消费。

消费者在拿到消息以后，它已经将消息存在DB里面了，它已经完成它的业务了，正常要返回ack，只剩下最后一步提交offset，但是在提交offset的时候，不巧消费者挂掉了，那么意味着这个offset没有办法被提交。

一旦消费者挂掉，这个时候就会触发同组的消费者reblacne机制，触发重新分配。也就就是把之前消息的messagequenue从新分配给新的consumer，也就是同组的另外一个消费者。

因为这个消息没有提交offset，所以出现的问题就在于在提交offset的时候，consumer已经挂掉了，那么这个消费者再过来对messagequenue进行消费依然是可以拿到这条消息的。

这在于提交的时候consumer挂掉了，新的消费者拿到这条消息又把这个消息添加到数据库里面。消息的重试可能导致对消息的重复消费。那么就会出现幂等性的问题。

上面两种逻辑都会出现幂等性问题。

可以在业务侧方面去做幂等性的保证

如何保证幂等性消费？

mysql 插⼊业务id作为主键，主键是唯⼀的，所以⼀次只能插⼊⼀条

很不幸生产者发送了两条消息，那么消费者将就会收到两条消息，最后这两条消息存在数据库里面。

或者在消费完一条消息的时候，在提交offset的时候，消费者1挂掉了，然后消费者2继续将这条消息存放到数据库里面。

无论是生产者还是消费者，出现这种问题的时候可以使用数据库主键来解决。

在消息体里面使用订单id为主键，而不是使用数据库自增长ID，

使⽤redis或zk的分布式锁（主流的⽅案）在分布式场景下是一个很有效的，很通常的一个手段。

在业务层面有一个单独的组件管理着共享的数据，既然是单独的组件，那么必然数据可以被多个消费者访问。

现在有两个消费者C1 C2。，它就上了mylock1这样一个锁。注意这里做了一个上锁的动作。

如果上锁成功，很显然c2继续上锁，那么c2肯定是失败的。只要分布式锁保证数据不会出现脏读。

c1 c2都想消费一条消息，订单id都是相同的都是1。发现订单id为1那么就要做一件事情，去共享的中间者看看，去尝试上锁。能不能上成功？

如果这地方根本就没有mylock1那么就成功了，那么这个锁就上上去了。那么c1就可以对这条消息进行处理，将消息存放到数据库当中。

c2是在后面来的，也要去管理着共享数据的组件里面有没有mylock 订单id为1的。如果没有存在那么数据可以存在数据库当中。但是来的时候发现有这个数据存在了。说明c2上这个锁之前已经有其他的消费者上过这个锁了，也就是有其他消费者消费了这条消息了。

既然有其他消费者已经消费了，那么c2就不要消费了。

通过分布式锁解决了幂等性的问题。