文章详情页您现在的位置是：网站首页>文章详情

消息队列基础篇(下)

Jeyrce.Lu 发表于：2019年12月6日 19:07 分类：【服务器】 3374次阅读

消息队列在运行过程中也会有一些问题，接下来就讨论一下消息队列中重复消息问题和消息积压问题的处理方法。

一、如何处理消息重复问题

1.消息重复的必然性

上一篇我们讲到了消息队列为了保证消息可靠性，采取了分布式事务和消息回查机制，由于消息回查机制的存在，消息重复是必然存在的情况。

生产阶段，假如一条消息成功写入了消息队列，但是应答信号ACK在回传给Producer的过程中丢失，就会导致这条消息重复写入消息队列，那么消费端就会收到重复消息。

消费阶段，假如一条消息被成功消费，但是应答信号ACK回传给Broker的过程中丢失，消息就会再次推送给消费者产生重复消费。

2.消息服务质量

在MQTT协议中规定了三个等级的消息服务质量：

（1）At most once：至多一次。消息在传递时，最多会被送达一次。换一个说法就是，没什么消息可靠性保证，允许丢消息。

（2）At least once：至少一次。消息在传递时，至少会被送达一次。也就是说，不允许丢消息，但是允许有少量重复消息出现。

（3）Exactly once：恰好一次。消息在传递时，只会被送达一次，不允许丢失也不允许重复，这个是最高的等级。

三种消息质量等级消息准确性逐渐升高，实现难度也逐渐升高。那么我们是否可以通过使用消息队列中间件时设定Exactly once等级，让消息队列中间件本身来帮助我们既保证消息可靠性又没有消息重复呢？答案是：不能。目前包括Kafa在内的绝大多数消息队列中间件能够提供的消息等级是At least once。

3.幂等原理

（1）数学中的幂等: f(x) = f(x)^n

（2）引申的幂等: 一个或一串操作执行1次和执行n次造成的结果是相同的，那么这一串操作就是幂等操作。

（3）基于幂等的原理，对于消息消费结果来说：Exactly once = At least once + 幂等消费

4.如何设计幂等消费

消息中间件为At least once等级，我们只要保证消费是幂等消费，那么就能解决消息重复的问题。但是并不是所有的消费都是幂等的，因此我们需要在业务逻辑中利用一些组件的性质将非幂等消费转换为幂等消费。

常见的设计幂等消费的技巧：

（1）利用数据库唯一性约束：实际上不仅是唯一性，类似于CREATE IF NOT EXIST, SETNX等这样的约束都可以。

（2）设置前置消费条件：满足条件则消费并返回成功ACK，否则只返回成功ACK。

（3）GUID方案：每条消息设置全局唯一id，消费前先检查当前消息的id是否已经消费过，未消费过则消费后标记id返回成功ACK，否则直接返回成功ACK。

用一句话来概括就是：设计好幂等消费，就可以解决消息重复问题。