选Redis做MQ的人，是脑子里缺根弦儿吗？

V-xin：ruyuan0330 获得600+页原创精品文章汇总PDF

目录

• 一、前情提示
• 二、unack消息的积压问题
• 三、如何解决unack消息的积压问题
• 四、高并发场景下的内存溢出问题
• 五、低吞吐量问题
• 六、合理设置prefetch count 七、阶段性总结

---

一、前情提示

上一篇文章：《RocketMQ消息中间件用起来真的可靠吗？》，我们分析了ack机制的底层实现原理（delivery tag机制），还有消除处理失败时的nack机制如何触发消息重发。

通过这个，已经让大家进一步对消费端保证数据不丢失的方案的理解更进一层了。

这篇文章，我们将会对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正在投递一条消息到cha