2

サーバー B にサーバー A からプロセスを開始するように指示し、完了したらサーバー A でインポート スクリプトを実行するように調整したいと考えています。このシナリオで SQS を正しく使用する方法を理解するのに苦労しています。 .

サーバー A: メインの専用サーバー サーバー B: クラウド プロセス サーバー

  • サーバーAはSNS経由でSQSにメッセージを送信し、「プロセスを開始します」と言います
  • サーバー B は、「プロセスの開始」メッセージの SQS を常にポーリングします
  • サーバー B は、SQS で「プロセスの開始」メッセージを見つけます
  • サーバー B は「process.sh」ファイルを実行します
  • サーバー B は「process.sh」ファイルの実行を完了します
  • サーバー B は SQS から「開始プロセス」を削除します
  • サーバー B は SNS 経由で SQS にメッセージを送信し、「インポートの開始」と伝えます。
  • サーバー A は、「インポートの開始」メッセージの SQS を常にポーリングします
  • サーバー A は、SQS で「インポートの開始」メッセージを見つけます
  • サーバー A は import.sh を実行します
  • サーバー A は「import.sh」の実行を完了します
  • サーバー A は SQS から「インポートの開始」を削除します

これが SQS の使用方法ですか、それとも要点を完全に見逃していますか?

4

3 に答える 3

3

AmazonがSQSをサービスとして提供していることをお詫び申し上げます。これは「単純なキュー」ではなく、おそらくあなたの場合には最良の選択ではありません。具体的には：

  • 少量のメッセージングではパフォーマンスが非常に悪くなります（一部のメッセージは到着するまでに90秒かかります）
  • メッセージの順序は保持されません
  • メッセージを複数回配信するのが好きです
  • 彼らはあなたに投票料金を請求します

良いニュースは、それがうまくスケーリングすることです。しかし、何を推測するか、あなたはスケールの問題を抱えていないので、SQSの風変わりな振る舞いに対処することは、正当な理由もなくあなたに苦痛をもたらすでしょう。RabbitMQをチェックすることを強くお勧めします。これは、単純なキューが動作するのとまったく同じように動作します。

于 2013-03-13T16:50:19.693 に答える
1

ええと... SQS はメッセージ ルーティングをサポートしていません。サーバー A または B にメッセージを割り当てるために、利用可能な解決策の 1 つは、SNS トピック「サーバー a」および「サーバー b」を作成することです。これらのトピックは、アプリケーションがプルする SQS にメッセージを送信する必要があります。また、Web フック (メッセージを分析し、アプリケーションへのコールバックを行う SNS イベントのサブスクライバー) を実装することもできます。

于 2013-03-13T21:42:54.600 に答える
1

あなたがレイアウトしたものは理論的には機能しますが、私はメッセージを直接キューに入れるのではなく、それらのメッセージを SNS トピックに入れ、キューをトピックにサブスクライブしてそこに到達させます - より柔軟に変更できます本番環境のコードやサーバーに一切触れることなく、将来的に物事を進めることができます。

あなたが今していることには、SNSの部分は不要ですが、使用することで、将来的に既存のサーバーに触れることなく機能を変更することができます.

例: 変更が必要で、サーバー B で「プロセスの開始」が実行されるたびに開始されるプロセス C を追加したいとします。AWS SNS コンソールからすぐに、メッセージの 2 番目のコピーを別のキューに送信できます。存在せず、そのキューからポーリングするサーバー C をセットアップします (ファンアウト パターン)。

また、私が最初のロールアウト中によく行うのは、何が起こっているかを知るために SNS に通知を追加することです。つまり、「プロセスの開始」イベントが発生するたびに、携帯電話 (または電子メール アドレス) をトピックに登録して、通知 - 何が起こっているか (または起こっていないか) をリアルタイムで監視できます。本番環境へのデプロイ後、一定期間が経過したら、AWS コンソールに移動し、サーバーやコードに一切触れずに、プロセスからメール/セルのサブスクライブを解除するだけです。

于 2013-04-08T12:41:19.380 に答える