0
Amazon SQSでは、メッセージパブリッシャはキューを作成し、メッセージをパブリッシュします。しかし、キューからメッセージを消費するためには、クライアントは（明らかに）パブリッシャだけが知っているキューのURLを知る必要があります。メッセージパブリッシャーはキューURLについてクライアントにどのようにアドバイスしますか？
ここでキューのアーキテクチャの仕組みに何か不足していますか？
A
答えて
0
ここでキューのアーキテクチャの仕組みが不明ですか？
私はそう思っています。
キューにはプロデューサとコンシューマが含まれていますが、これらのエンティティのどちらも必ずキューを作成しません。どちらも、何らかの仕組みによって、もちろんURLを知る必要がありますが、そのようなことはアプリケーションに完全に依存しています。
キュー（したがってそのURL）はプロデューサではなく、プロビジョニングプロセス（自動または手動）で永続的（一時的ではない）で作成され、作成されることがよくあります。
プロデューサがキューを作成することは可能ですが、コンシューマはキューを作成し、最終的に送信されるメッセージを送信するプロデューサになるプロセスに（直接的または間接的に）アドバイスすることもできます。
ワーカープロセスが1つのキューの消費者であり、プロデューサが別のキューのコンシューマになることも、ワーカーが複数のキューと対話することも珍しくありません。この例では
"W" = workers, "P" = producer, "C" = consumer, "Q" = queue, "T" = task
W1 (now a producer) >> Q1 >> "Please perform task T1 and send results to Q2"
W2 (now a consumer) << Q1 << "Please perform task T1 and send results to Q2"
W2 (performs task T1)
W2 (now a producer) >> Q2 >> "Here are the results from task T1"
W1 (now a consumer) << Q2 << "Here are the results from task T1"
、W1は、Q1とQ2の消費者のための生産者です。 Q1（要求を送信する場所）とQ2（送信する応答を要求する場所）の両方のURLを知る必要があります。 Q1のプロデューサーはQ1を作成する責任を負いません。 Q1は既に存在するでしょう。それはが消費者になるQ2を作成する責任があります。
逆に、W2は、消費者に割り当てられているキューであるQ1のURLだけを知っている必要があります。上記のように、Q1はすでに存在している可能性が高く、URLはW1とW2の両方に提供されます（おそらく、最初に起動されたとき）。着信要求はQ2のURLをW2に知らせるか、W2は常にその結果をQ2に返すことがあります。その場合、W1は元のメッセージでこれを指定する必要はありません。
キューの作成者と、キューのプロデューサーおよび/またはコンシューマーがキューURLを知る方法は、アーキテクチャープロセスの一部です。プロデューサーを示唆する一般的な原則はほとんどありませんキューの最も有望な作成者になります。キューが使用される理由とワークフローの性質に強く依存するのは誰ですか。