私はこのチュートリアルに従っています: http://boto.s3.amazonaws.com/sqs_tut.html
キューに何かがある場合、それを処理するために 20 人のワーカーの 1 つを割り当てるにはどうすればよいですか?
私はPythonを使用しています。
私はこのチュートリアルに従っています: http://boto.s3.amazonaws.com/sqs_tut.html
キューに何かがある場合、それを処理するために 20 人のワーカーの 1 つを割り当てるにはどうすればよいですか?
私はPythonを使用しています。
残念ながら、SQS には、キューでよく期待されるセマンティクスの一部が欠けています。通知や「get」呼び出しをブロックするようなものはありません。
Amazon の関連する SNS/簡易通知サービスは、この作業に役立つ場合があります。作業をキューに追加したら、サブスクライブしたワーカーに通知を送信できます。
以下も参照してください。
これは (現在) SQS キューでのロング ポーリングで可能です。
http://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/Query_QueryReceiveMessage.html
ロング ポールのサポート (1 ~ 20 の整数) - メッセージがまだキューにない場合に空の応答を返すのではなく、メッセージがキューに入れられて応答に含まれるまで、ReceiveMessage アクション呼び出しが待機する期間 (秒単位)。利用可能。
要求で WaitTimeSeconds を指定しない場合、キュー属性 ReceiveMessageWaitTimeSeconds を使用して待機時間を決定します。
タイプ: 0 から 20 までの整数 (秒)
デフォルト: キューの ReceiveMessageWaitTimeSeconds。
SQS の問題をさらに指摘するには、新しい通知をポーリングする必要があります。特定のポーリングで、キューに存在するイベントを受け取るという保証はありません (これは、アーキテクチャの冗長性によるものです)。これは、ポーリングが存在するメッセージを返さなかった可能性を考慮する必要があることを意味します (これは、ポーリング レートを上げる必要があることを意味します)。
全体として、SQS にはあまりにも多くの制限があることがわかりました (SimpleDB などの他の AWS ツールで見つけたように)。しかし、それは私の注入された意見です。
実際、低レイテンシが必要ない場合は、これを試すことができます:
キューに cloudwatch アラームを作成します。たとえば、メッセージが表示されたり、受信したメッセージが 0 を超えたりします。アクションとして、sns トピックにメッセージを送信し、そのメッセージを http/s エンドポイント経由でワーカーに送信できます。
通常、この種のアプローチは自動スケーリングに使用されます。