一千萬個為什麽

搜索

如何確保在分布式系統設置中公平分配SQS消息?



我有多個服務器,每個都有一個腳本輪詢SQS隊列[全部輪詢同一隊列]。

那麽,我有什麽方法可以確保向所有這些客戶公平分配消息[即我的工作服務器]。例如,如果隊列中有100條消息,則有 20-20-20-20-20 (如果有5個工作人員),依此類推。

AWS ELB(彈性負載平衡器)可以幫助我做到這一點嗎?如果是,那麽如何?如果沒有,那麽AWS生態系統中是否有替代服務可以幫助我做到這一點?

Or am I overthinking this? I mean, can this be solved straightforwardly in the polling script? [Please keep in mind the race conditions involved due to multiple clients polling a single queue]

轉載註明原文: 如何確保在分布式系統設置中公平分配SQS消息?

一共有 3 個回答:

如果隊列中有100條消息和5位消費者,則初始分配不會超過10-10-10-10-10。

A single response can never return more than 10 messages.

這似乎是一個非問題。

與多個消費者相關的競爭條件也應該不是問題。 SQS是針對多個同時使用的消費者而設計的。

使用長時間的民意調查和20秒的最大等待時間,並感到驚訝。 (不,20秒等待不會延遲20秒,它不會延遲它們,你需要看到它的行動才能真正理解它是如何工作的。)

我懷疑你肯定在推翻一些東西。

如何使用SQS隊列的良好架構將解決您的問題。如果我們假設每個消息有3分鐘的處理時間,那麽幾乎可以保證消息的平均分配,因為與輪詢隊列所需的時間相比,這是非常大的,如果僅在消息從隊列中刪除後它已被處理。

請註意,任何SQS消息都有12小時的可見性超時限制,所以如果您在此之前不刪除它,它將重新出現在隊列中。我懷疑這可能不是對你的限制,但請牢記它。

長時間輪詢總是有益的,因為它在大多數用例中以更低的成本獲得更高的性能。不幸的是,由於隊列的分布式特性,你無法控制每個工作人員從隊列中接收的消息數量。但是有一些客戶端解決方案可以幫助您平衡工作者的負擔。

So, this is what we did as a workaround for this:

作為解決方法之一,輪詢器腳本可以控制每個工作人員接收的消息數量。可以為每個工作人員可以處理的最大消息數設置閾值。此閾值可以是動態值,可能是 ApproximateNumberOfMessagesVisible 除以輪詢器/輪詢器腳本的數量。然後,您可以將可見性超時保持為任何較小的值,因此如果所有輪詢腳本同時進行長輪詢,其中一個輪詢器會抓取該消息,根據閾值決定它是否過載,不會刪除消息,消息可以回到隊列中,並且可以被仍然有能力獲取消息的其他輪詢者抓住。閾值參數可以進行微調以滿足應用程序的需求。


此外,具有故障轉移機制也會有所幫助,就像這篇文章中的答案描述一樣。但是,我不能在分布式架構中擁有故障轉移隊列,因為這會增加復雜性。所以,上述解決方法對我的團隊來說是一個更好的主意。