消息队列的堆积问题

最近折腾项目，因为项目里用到了RabbitMQ，所以会经常看控制台。控制台中出现了这样一个问题：队列中的消息产生了堆积现象，也就是说消费者的消费速度赶不上生产者生产的速度。

这会导致结果产出变慢，从而侧面影响用户的体验。经过反复思考，我将解决方案总结如下，其中包括我自己的思考以及部分来源于网上的解决方法。

解决方案

1.暂时性解决堆积问题，快速解决项目痛点。

2.根本性解决问题，但有概率翻车。

暂时性解决，即通过更大程度的限流来减缓消息的涌入，这种方案好在本身的稳定性上，可以理解为解决不了问题，就解决了提出问题的人。这样做的坏处也显而易见，消息队列的堆积问题解决了，但是用户的体验并没有变好，反而变得更差，因为被限流了。

根本性解决，即通过增加消费速度来加速消息的消费，这种方案好在效果上，可以根本性解决消息堆积问题和衍生出来的用户体验问题。但是坏处就是有概率翻车，因为增加消费速度可以通过修改消费本身逻辑和增加消费者的个数来实现，但无论是消费逻辑，还是消费者的个数，都需要你的业务原生支持。

原生支持的意思在这里做一解释：假设你的业务逻辑是调用他人的API，那么消费逻辑就是简单的调用，按照上文根本性解决方案，对于消费逻辑的优化在API提供方那里，你能做的只有调用，那么优化空间几乎没有；而增加消费者个数也就是要求API提供方支持并发调用API，这一点也取决于API的提供方。

这样看来貌似哪一种方案都达不到优雅地解决问题，最后项目解决方案选择了后者，因为项目本身消费逻辑是可以进一步优化的，在优化后增加消费者，最终解决消费队列的堆积问题。

读者也可以在评论区各抒己见，互相学习，有更好的解决方案也可以放在评论区里，欢迎讨论！