Stellt eine Antwort auf eine HTTP-Anfrage bereit, nachdem eine andere Anfrage empfangen wurde

php-Editor Erdbeere Bei der Entwicklung von Webanwendungen müssen wir häufig HTTP-Anfragen verarbeiten und entsprechende Antworten bereitstellen. Wenn wir eine Anfrage erhalten, müssen wir eine angemessene Antwort generieren, die auf dem Inhalt und Zweck der Anfrage basiert. Dies kann verschiedene Vorgänge wie das Abfragen der Datenbank, das Verarbeiten von Formulardaten, den Aufruf anderer APIs usw. umfassen. In diesem Artikel untersuchen wir, wie HTTP-Anfragen in PHP verarbeitet und entsprechende Antworten bereitgestellt werden, um den Benutzern eine bessere Interaktion und Benutzererfahrung zu bieten. Unabhängig davon, ob Sie eine einfache statische Webseite oder eine komplexe Webanwendung erstellen, ist es wichtig zu verstehen, wie HTTP-Anfragen verarbeitet und Antworten generiert werden.

Frageninhalt

Mein Anwendungsfall besteht darin, die Antwort auf eine HTTP-Anfrage bereitzustellen, nachdem eine andere Anfrage von einem separaten Server empfangen wurde.

1. Ich möchte dies auf die bestmögliche Weise tun und dabei die Skalierbarkeit im Auge behalten.
2. Wir verwenden Golang 1.19 und das Gin-Framework.
3. Der Server verfügt über mehrere Pods, sodass Kanäle nicht funktionieren.
4. Alle Anfragen werden abgebrochen, die erste Anfrage wird nach 60 Sekunden abgebrochen.

Meine aktuelle Lösung besteht darin, einen gemeinsamen Cache zu verwenden, bei dem jeder Pod den Cache ständig überprüft. Ich glaube, ich kann dies optimieren, indem ich das System so kanalisiere, dass es regelmäßig nach abgeschlossenen Antworten sucht, anstatt den Cache einzeln zu überprüfen.

Ich würde auch gerne wissen, wie man es in anderen Programmiersprachen umsetzt.

PS: Dies ist eine designbasierte Abfrage und ich habe den Ruf, hier Kopfgelder zu teilen, also frage ich hier. Wenn die Frage unklar ist, können Sie sie gerne bearbeiten.

Lösung

tl;dr

Problembeschreibung

Angenommen, Ihre Serveranwendung heißt server_app und verfügt über 3 Pods:

+---------------------+
     |  server_app_service |
     +---------------------+
     |  server_app_pod_a   |
     |  server_app_pod_b   |
     |  server_app_pod_c   |
     +---------------------+

Ihr Dienst erhält eine Anfrage mit dem Namen "request a" und beschließt, diese an server_app_pod_a weiterzuleiten. Jetzt leitet Ihr server_app_pod_a die Anfrage an ein Gateway weiter und wartet auf eine Art "request a" 的请求，并决定将其传递给 server_app_pod_a。现在，您的 server_app_pod_a 将请求转发到某个网关，并等待某种通知，以继续处理客户端的响应。正如您所知，无法保证当网关执行 request b 时，服务会再次将其传递给 server_app_pod_aBenachrichtigung

, um mit der Verarbeitung der Antwort des Clients fortzufahren. Wie Sie wissen, gibt es keine Garantie dafür, dass, wenn das Gateway request b ausführt, der Dienst es erneut an server_app_pod_a weiterleitet. Selbst wenn Sie dies tun, wird die Statusverwaltung der Anwendung zu einer schwierigen Aufgabe.

Messaging

request“b”Wie Sie vielleicht bemerkt haben, habe ich das Wort „Benachrichtigung“ im vorherigen Absatz fett gedruckt, denn wenn Sie wirklich darüber nachdenken, sieht eher wie eine Benachrichtigung mit einer Nachricht

aus als wie eine Nachricht an jemanden, der nach Ressourcen fragt. Daher ist meine erste Wahl eine Nachrichtenwarteschlange wie Kafka (wie Sie wissen, gibt es viele davon). Die Idee besteht darin, dass Sie, wenn Sie einen Algorithmus zur Berechnung des eindeutigen Schlüssels einer Anfrage definieren können, im selben Pod über das Ergebnis benachrichtigt werden können. Auf diese Weise wird die Statusverwaltung einfacher und die Chance, Benachrichtigungen im selben Pod zu erhalten, ist höher (natürlich hängt dies von vielen Faktoren ab, z. B. dem Status der Nachrichtenwarteschlange). Schauen Sie sich Ihre Fragen an:

Ich möchte dies auf die bestmögliche Weise tun und dabei die Skalierbarkeit im Auge behalten.

Natürlich können Sie diese Nachrichtenwarteschlangen wie Kafka verwenden, um die Skalierung von Nachrichtenwarteschlangen und Anwendungen zu ermöglichen und Datenverluste zu reduzieren.

Alle Anfragen werden abgebrochen, die erste Anfrage wird nach 60 Sekunden abgebrochen.

Je nachdem, wie Sie Zeitüberschreitungen in Ihrer Codebasis verwalten, ist die Verwendung von Kontext eine gute Idee.

Ich würde auch gerne wissen, wie man es in anderen Programmiersprachen umsetzt.

scala 中，如果您使用一些名为 akka 的特定工具（它提供了 actor 模型编程范例），您可以使用所谓的 akka-cluster-shardingDie Verwendung einer Nachrichtenwarteschlange ist eine allgemeine Idee, die mit fast jeder Programmiersprache funktioniert. Abhängig vom Programmierparadigma der Sprache und den sprachspezifischen Bibliotheken und Tools gibt es jedoch möglicherweise andere Möglichkeiten, dieses Problem zu lösen. Zum Beispiel in

, um dieses Problem zu lösen. Die Idee ist ganz einfach: Wir wissen, dass es eine Art Supervisor geben muss, der den genauen Standort und Status seiner eigenen Abonnenten kennt. Wenn es also eine Nachricht empfängt, weiß es einfach, wohin und an welchen Akteur die Anfrage weitergeleitet werden soll (wir sprechen hier von Akteurmodellprogrammierung). Mit anderen Worten: Es kann verwendet werden, um den Status zwischen den in einem Cluster erzeugten Teilnehmern zu teilen, unabhängig davon, ob sie sich auf demselben Computer befinden oder nicht. Aber aus persönlichen Gründen würde ich mich nicht für eine sprachspezifische Kommunikation entscheiden und bei der allgemeinen Idee bleiben, da dies in Zukunft zu Problemen führen könnte.

Zusammenfassung

Lange genug Erklärung :). Um zu verstehen, wovon ich spreche, verfolgen wir genau dasselbe Szenario, jedoch mit einem anderen Kommunikationsmodell: 🎜

1. Der Client sendet die Anfrage „a“ an den server_app-Dienst.
2. Der Dienst wählt einen der Pods (z. B. server_app_pod_b) aus, um die Anfrage zu bearbeiten.
3. Dann versucht der Pod, einen Schlüssel für die Anfrage zu definieren, leitet ihn zusammen mit der Anfrage an das Gateway weiter und wartet, bis eine Nachricht mit diesem Schlüssel in der Warteschlange veröffentlicht wird.
4. Das Gateway tut, was es tun soll und sendet die Nachricht mit der Taste an die Nachrichtenwarteschlange.
5. Genau derselbe Pod serer_app_pod_b empfängt die Nachricht mit dem Schlüssel, ruft die Daten der Nachricht ab und verarbeitet die Anfrage des Clients weiter.

Es gibt vielleicht andere Möglichkeiten, dieses Problem zu lösen, aber das ist es, was ich möchte. Hoffe es hilft dir!

Das obige ist der detaillierte Inhalt vonStellt eine Antwort auf eine HTTP-Anfrage bereit, nachdem eine andere Anfrage empfangen wurde. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!