別のリクエストを受信した後、HTTP リクエストに応答します。

php エディター イチゴ Web アプリケーションを開発するとき、多くの場合、HTTP リクエストを処理し、対応するレスポンスを提供する必要があります。リクエストを受け取った場合、リクエストの内容と目的に基づいて適切な応答を生成する必要があります。これには、データベースへのクエリ、フォーム データの処理、他の API の呼び出しなど、さまざまな操作が含まれる場合があります。この記事では、ユーザーにより良い対話とユーザー エクスペリエンスを提供するために、PHP で HTTP リクエストを処理し、対応するレスポンスを提供する方法を説明します。単純な静的 Web ページを構築する場合でも、複雑な Web アプリケーションを構築する場合でも、HTTP リクエストを処理し、応答を生成する方法を理解することが重要です。

質問の内容

私の使用例は、別のサーバーから別のリクエストを受信した後、HTTP リクエストに対する応答を提供することです。

1. スケーラビリティを念頭に置きながら、可能な限り最善の方法でこれを実行したいと考えています。
2. Golang 1.19 と Jin フレームワークを使用します。
3. サーバーには複数のポッドがあるため、チャネルは機能しません。
4. すべてのリクエストはタイムアウトになります。最初のリクエストは 60 秒後にタイムアウトになります。

私の現在の解決策は、各ポッドがキャッシュを常にチェックする共有キャッシュを使用することです。これは、キャッシュを 1 つずつチェックするのではなく、システムが完了した応答を定期的にチェックするチャネリングによってこれを最適化できると考えています。

他のプログラミング言語で実装する方法も知りたいです。

PS: これはデザインベースのクエリであり、私はここで報奨金を共有することである程度の評判があるので、ここで質問します。質問が不明瞭な場合は、自由に編集してください。

解決策

tl;医師

問題の説明

したがって、サーバー アプリケーションの名前が server_app であると仮定すると、たとえばポッドが 3 つあります:

リーリー

あなたの サービス は、"request a" という名前のリクエストを受信し、それを server_app_pod_a に渡すことを決定します。ここで、server_app_pod_a はリクエストを何らかのゲートウェイに転送し、クライアントの応答の処理を続行するために何らかの種類の notification を待ちます。ご存知のとおり、ゲートウェイが request b を実行するときに、サービスがそれを再び server_app_pod_a に渡すという保証はありません。これをやったとしても、アプリケーションの状態管理は困難になります。

メッセージパッシング

お気づきかと思いますが、前の段落では「通知」という単語を太字にしました。よく考えてみると、request "b" は、「There are notification for some ##」のように見えるからです。 # メッセージ 特定のリソースに対するリクエストの代わりに。したがって、私の最初の選択肢は、kafka のようなメッセージ キューです (ご存知のとおり、メッセージ キューはたくさんあります)。アイデアは、リクエストの一意のキーを計算するアルゴリズムを定義できれば、まったく同じポッドで結果を通知できるということです。こうすることで、状態管理がより簡単になり、同じポッドで通知を取得できる可能性が高くなります (もちろん、これはメッセージ キューの状態などの多くの要因によって異なります)。あなたの質問を見てください:

スケーラビリティを念頭に置きながら、可能な限り最善の方法でこれを実行したいと考えています。

もちろん、これらのメッセージ キューを kafka のように使用して、メッセージ キューとアプリケーションのスケーリングを実現し、データ損失を減らすことができます。

すべてのリクエストはタイムアウトになります。最初のリクエストは 60 秒後にタイムアウトになります。

コード ベースでタイムアウトを管理する方法によっては、コンテキストを使用することをお勧めします。

他のプログラミング言語で実装する方法も知りたいです。

メッセージ キューの使用は、ほぼすべてのプログラミング言語に当てはまる一般的な考え方ですが、言語のプログラミング パラダイムや言語固有のライブラリとツールによっては、この問題を解決する他の方法がある場合があります。たとえば、

scala では、akka (アクター モデル プログラミング パラダイムを提供する) という特定のツールを使用する場合、いわゆる akka-cluster-sharding ## を使用できます。 # この問題に対処します。アイデアは非常に単純です。自分の加入者の正確な位置とステータスを知っているある種のスーパーバイザが必要であることがわかっています。したがって、何らかのメッセージを受信すると、リクエストをどこに転送するか、どのアクターに転送するかを認識するだけです (これはアクター モデルのプログラミングについて話しています)。言い換えれば、同じマシン上かどうかに関係なく、クラスター上に生成された参加者間で状態を共有するために使用できます。しかし、個人的な好みとして、私は言語固有のコミュニケーションをとらず、将来問題を引き起こす可能性があるため、一般的な考え方に固執します。 要約

十分長い説明です :)。私が何を言っているのかを理解するために、まったく同じシナリオを、異なる通信モデルで追跡してみましょう:

1. クライアントはリクエスト「a」を server_app サービスに送信します。
2. サービスは、リクエストを処理するポッドの 1 つ (例: server_app_pod_b) を選択します。
3. その後、ポッドはリクエストのキーを定義しようとして、それをリクエストとともにゲートウェイに渡し、そのキーを含むメッセージがキューに公開されるまで 待機します。
ゲートウェイは本来の動作を実行し、キー
4. を使用してメッセージ をメッセージ キューに送信します。
まったく同じポッド
5. serer_app_pod_b キーを含むメッセージを受信し、メッセージのデータを取得して、クライアントのリクエストの処理を続行します。

この問題を解決するには他の方法があるかもしれませんが、これが私が望むものです。お役に立てば幸いです!

以上が別のリクエストを受信した後、HTTP リクエストに応答します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。