所以，有什么办法可以确保将消息公平地分配给所有这些客户端[即我的工作人员服务器在这里]。例如，如果队列中有100条消息，那么如果队列中有5个工作线程，则依次类推。以此类推。
AWS ELB（弹性负载平衡器）可以帮助我吗？如果是，那怎么办？如果没有，那么AWS生态系统中是否有一项替代服务可以帮助我做到这一点？
还是我对此是否考虑过度？我的意思是，这可以在轮询脚本中直接解决吗？ [请记住由于多个客户端轮询单个队列而导致的竞争条件]
#1 楼
如果队列中有100条消息和5个使用者，则初始分发将不超过10-10-10-10-10。单个响应永远不会返回超过10条消息。
这似乎不是问题。
与多个消费者相关的竞赛条件也应该不是问题。 SQS专为多个同时使用的消费者而设计。
使用长时间轮询和20秒的最大等待计时器会感到惊讶。 （不，等待20秒不会使消息延迟20秒。它根本不会延迟消息。您需要真正地了解它的工作原理才能真正理解它的工作原理。）
您我怀疑肯定是在考虑一些事情。
#2 楼
使用SQS队列的良好体系结构将解决您的问题。如果我们假设每个消息有3分钟的处理时间，那么您几乎可以保证消息的均等分布，因为与轮询队列所需的时间相比，这是非常大的，如果仅在之后才从队列中删除消息请注意，任何SQS消息都有12小时的可见性超时限制，因此，如果您届时不删除它，它将重新出现在队列中。我怀疑这可能不是对您的限制，但请记住这一点。
#3 楼
长轮询始终是有益的，因为它可以在大多数用例中以较低的成本获得更高的性能。不幸的是，由于队列的分布式性质，您无法控制每个工作进程从队列接收的消息数量。但是有一些客户端变通办法可以帮助您平衡工作人员的负担。因此，这是我们作为变通办法所做的：
解决方法中，轮询程序脚本可以控制每个工作人员收到的消息数。可以为每个工作者可以处理的最大邮件数设置一个阈值。该阈值可以是一个动态值，可能是
ApproximateNumberOfMessagesVisible除以轮询器/轮询器脚本的数量。然后，您可以将可见性超时保持为任何较低的值，因此，如果所有轮询器脚本都同时进行长时间轮询，则其中一个轮询器将抓取该消息，并基于阈值确定它已过载，不删除该消息，该消息回到队列中，其他仍有能力抓取消息的投票者可以抓住它。可以对阈值参数进行微调以满足应用程序的需求。此外，具有故障转移机制也将有所帮助，就像本文中的答案所描述的那样。但是，我不能在分布式体系结构中拥有故障转移队列，因为这会增加复杂性。因此，上述解决方法对我的团队来说是一个更好的主意。
评论
可能与：D相关