分散システム設定でのSQSメッセージの公平な分散を確実にする方法は？

複数のサーバーがあり、それぞれにSQSキューをポーリングするスクリプトがあります（すべて同じキューをポーリングします）。

それで、それらすべてのクライアント（つまり、ここの私のワーカーサーバー）へのメッセージの公平な配布を保証できる方法はありますか？たとえば、キュ​​ーに100のメッセージがある20-20-20-20-20場合、5つのワーカーがある場合などです。

AWS ELB（Elastic Load Balancer）はそれを行うのに役立ちますか？はいの場合、どのように？そうでない場合、AWSエコシステムには、私がそれを行うのに役立つ代替サービスがありますか？

それとも私はこれを考えすぎていますか？つまり、これはポーリングスクリプトで直接解決できますか？[複数のクライアントが単一のキューをポーリングすることによる競合状態に注意してください]

キューに100のメッセージがあり、5つのコンシューマーがある場合、最初の配布は10-10-10-10-10以下になります。

単一の応答が10を超えるメッセージを返すことはありません。

これは問題ではないようです。

複数の消費者に関連する競合状態も問題ではありません。SQSは、複数の同時コンシューマー向けに設計されています。

長い投票と最大20秒の待機タイマーを使用して、驚かされます。（いいえ、20秒待機してもメッセージは20秒遅れることはありません。メッセージが遅れることはありません。実際に動作を確認して、動作を理解する必要があります。）

あなたは間違いなくいくつかのことを考えすぎていると思います。

SQSキューの使用方法に関する優れたアーキテクチャーは、問題を解決します。たとえば、メッセージごとに3分の処理があると仮定すると、メッセージをキューからポーリングするのに必要な時間と比べて非常に大きいため、メッセージの均等な分散をほぼ保証できます。処理されました。

SQSメッセージには12時間の表示タイムアウト制限があるため、その時間までに削除しないと、キューに再び表示されることに注意してください。これはおそらく制限ではないと思いますが、覚えておいてください。

ロングポーリングは、ほとんどのユースケースでパフォーマンスを向上させ、コストを削減できるため、常に有益です。残念ながら、キューの分散された性質のため、各ワーカーがキューから受信するメッセージの数を制御することはできません。ただし、ワーカーの負荷を分散するのに役立つクライアント側の回避策がいくつかあります。

だから、これは私たちがこれの回避策としてやったことです：

回避策の1つとして、ポーラースクリプトは、各ワーカーが受信するメッセージの数を制御できます。各ワーカーが処理できるメッセージの最大数にしきい値を設定できます。このしきい値は動的な値にすることができ、おそらくApproximateNumberOfMessagesVisibleポーラー/ポーラースクリプトの数で除算されます。次に、可視性タイムアウトを任意の低い値に保つことができるため、すべてのポーラースクリプトが同時に長時間ポーリングしている場合、ポーラーの1つがメッセージを取得し、しきい値に基づいて過負荷であると判断し、メッセージを削除しません。メッセージキューに戻り、まだメッセージを取得する能力を持っている他のポーラーによって取得される可能性があります。しきい値パラメーターは、アプリケーションのニーズに合わせて微調整できます。

また、この投稿の回答で説明されているように、フェイルオーバーメカニズムも役立ちます。ただし、分散アーキテクチャではフェイルオーバーキューを使用する余裕はありません。これは、複雑さが増すためです。したがって、上記の回避策は私のチームにとってより良いアイデアでした。