本文主要是介绍消费幂等、消息堆积及其解决方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
消费幂等：重复消费的结果与消费一次的结果是相同的，并且多次消费并未对业务产生任何负面影响，那么这个消费过程就是消费幂等。
消费重复的常见情况：
1、发送时重复：producer成功发送消息到broker并且完成了持久化，但在producer收到来自broker的成功消息之前的断开了，那么producer就会认为消息发送失败并尝试再次发送。这俩次发送消息的内容相同且messageId也相同。
2、消费时重复：消息已投递给consumer且完成业务处理，但在broker收到来自consumer的成功信息之前连接断开了，broker就会认为发送失败并再次投递该已被消费的消息。
3、rebalance时消息重复。
消息幂等解决方案：
涉及俩个要素：
幂等令牌：是生产者和消费者俩者中的既定协议，通常指具备唯一业务标识的字符串，一般由producer随着消息一同发送过来。
唯一性处理：服务端通过采用一定的算法策略，保证同一个业务逻辑不会被重新执行多次。
解决方案，有一下3步：
1、首先通过缓存去重。在缓存中如果已经存在了某幂等令牌，则说明本次操作是重复性操作，若未命中则进入下一步。
2、在唯一性处理前，先在数据库中查询幂等令牌作为索引的数据是否存在。存在，则说明本次操作为重复操作，若不存在，则进入下一步。
3、唯一性处理后，将幂等令牌写入缓存，并将幂等缓存作为唯一索引的数据写入DB中。
消息堆积：消息处理过程中，如果consumer的消费速度跟不上producer的发送速度，MQ中未处理的消息就会越来越多，这部分消息就被称为堆积消息。消息堆积而会造成消费延迟。
consumer对消息的操作分为俩步：消息拉取和消息消费。那么消息堆积会发生在哪一步呢？
消息拉取：consumer采用长轮询pull模式批量拉取获取消息，拉取式消费，在内网环境下会有很高的吞吐量，所以一般不会称为消息堆积的瓶颈。
消息消费：consumer使用业务逻辑对消息进行处理，完毕后获取到一个结果。此时consumer的消费能力完全依赖于消息的消费耗时和消费并发度了。很可能导致消息堆积。
消息堆积主要瓶颈在客户端的消费能力，消费能力有消费耗时和消费并发度决定。消费耗时优先级高于消费并发度。
消费耗时：影响消息处理时长的主要因素是代码逻辑。而代码中可能影响处理时长的代码有俩种：cpu内部计算型外码和外部I/O操作性代码。
通常情况下代码如果没有复杂的递归和循环的话，内部计算机耗时相对于外部I/O操作来说几乎是可以忽略的。所以外部I/O型代码是影响消息处理时长的主要症结所在：
1、读写外部数据库
2、读写外部缓存系统
3、下游系统调用
通常消息堆积是由于上下游系统出现了服务异常或达到了DBMS容量限制，导致消费耗时增加。
消息并发度：
一般，消费者端的消费并发度由单节点线程数和节点数量共同决定，其值为单节点线程数（即单个consumer包含的线程数）*节点数量（即consumer group包含的consumer数量）。不过通常需要优先调整单节点的线程数，若单机硬件资源达到了上限，则需要通过横向扩展提高消费并发度。
对于普通消息、延迟消息及事务消息，并发度都是单节点线程数*节点数量。但对于顺序消息是不同的，顺序消息并发度等于topic的queue分区数量（因为queue的处理不是并发的，而是queue处理完一个，才能处理下一个）。
这篇关于消费幂等、消息堆积及其解决方案的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
