我们有几个消费者流程，它们从标准SQS进行轮询并处理消息。每条消息都与一个用户相关联。对于每个用户，我们每分钟可以处理100条消息。除此之外，我们用于处理的API将开始给出500个错误。
现在，由于队列中包含其他用户的消息，我们无法挑选这些用户，因为他们的配额低于限制。
对此的一个解决方案是使用FIFO并实现消息组。但是先进先出有一个特殊的限制。
您最多可以有20000条飞行中的消息
这本来是完全可以的，但问题是，当一条消息从一个消息组传播时，SQS会将该组中所有消息的计数添加到传播中计数中。
这篇文章更详细地解释了：
https://tomgregory.com/3-surprising-facts-about-aws-sqs-fifo-queues/#:~：text=A%20FIFO%20队列%20具有%20a%20最大值%20空中%20消息%20限制%20%2020%2C000。
在这篇文章中，阅读">20000消息缓冲区"；头球这也许可以解释发生了什么。
https://aws.amazon.com/premiumsupport/knowledge-center/sqs-message-backlog/
我能想到的第二个解决方案是让微服务的生产者变得智能。但在我们的案例中，生产者是一个完全不同的微服务。而微服务的所有者几乎听不进去。
我们当然希望我们的消费者能够扩大规模，为每个用户提供最短的等待时间，但由于上述原因，我们做不到。
我真的觉得SQS不是这个设计的正确选择，但无法说服我的上级。
我们有办法克服这种情况吗？还是走到了死胡同？
这本来是完全可以的，但问题是当消息来自消息组，SQS将所有消息的计数相加该组中发送给飞行中计数的消息
我不认为FIFO是这种情况。我使用的是FIFO，每个消费者一次处理一条消息(共有3条(。有来自同一消息组的SQS消息，但对我来说，机上消息计数总是3，即3个消费者中的每一个都处理其中一个。当它们中的任何一个处理消息，并且每个SQS消息的处理时间在这里是可变的时，它会拾取队列中的下一个消息。机上信息计数始终保持为3。