本文深入探讨RabbitMQ的ack机制，分析unack消息积压问题及其解决方案——prefetch count。理解delivery tag，了解如何通过设置prefetch count防止内存溢出和提高吞吐量，同时讨论了过大会导致内存溢出，过小则影响吞吐量的问题，以及在实际应用中如何合理设置prefetch count。
这篇文章，我们将会对ack底层的delivery tag机制进行更加深入的分析，让大家理解的更加透彻一些。
面试时，如果被问到消息中间件数据不丢失问题的时候，可以更深入到底层，给面试官进行分析。
一、unack消息的积压问题
首先，我们要给大家介绍一下RabbitMQ的prefetch count这个概念。
大家看过上篇文章之后应该都知道了，对每个channel（其实对应了一个消费者服务实例，你大体可以这么来认为），RabbitMQ投递消息的时候，都是会带上本次消息投递的一个delivery tag的，唯一标识一次消息投递。
然后，我们进行ack时，也会带上这个delivery tag，基于同一个channel进行ack，ack消息里会带上delivery tag让RabbitMQ知道是对哪一次消息投递进行了ack，此时就可以对那条消息进行删除了。
大家先来看一张图，帮助大家回忆一下这个delivery tag的概念。
所以大家可以考虑一下，对于每个channel而言（你就认为是针对每个消费者服务实例吧，比如一个仓储服务实例），其实都有一些处于unack状态的消息。
比如RabbitMQ正在投递一条消息到channel，此时消息肯定是unack状态吧？
然后仓储服务接收到一条消息以后，要处理这条消息需要耗费时间，此时消息肯定是unack状态吧？
同时ÿ
最低0.47元/天 解锁文章
扫一扫
981
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
