Der Nginx-Wiederholungsversuch führt dazu, dass die HTTP-Anfrage wiederholt ausgeführt wird

1. Problemhintergrund

Die Website verwendet Nginx als Reverse-Proxy und zwei Tomcats führen den Lastausgleich durch.

Die Website verfügt über ein Gruppen-SMS-Modul, und der Administrator kann den Sendeinhalt und die Liste der Mobiltelefonnummern ausfüllen. Klicken Sie auf „Senden“ und der Gruppen-SMS-Vorgang wird im Hintergrund ausgeführt. Nach Abschluss des Versands wird das Sendeergebnis zurückgegeben.

Ich bin vor langer Zeit auf das Problem des wiederholten Sendens gestoßen. Zuerst dachte ich, der Administrator hätte sich ungewöhnlich verhalten und wiederholt auf die Schaltfläche „Senden“ geklickt. Daher gelten Einschränkungen für Front-End-Einreichungen. Wenn Sie auf „Senden“ klicken, stellen Sie die Schaltfläche auf „Deaktivieren“, um die zurückgegebenen Daten nach der Ausführung abzurufen, und setzen Sie sie dann auf „Verfügbar“, um wiederholte Übermittlungen vom Frontend zu begrenzen.

Heute hat ein Kollege dieses Modul plötzlich erneut verwendet und zwei Stapel Textnachrichten (8000 bzw. 1600) gesendet. Das Frontend meldet, dass der Vorgang fehlgeschlagen ist, sein Mobiltelefon jedoch doppelte Textnachrichten erhalten hat.

2. Problemanalyse

Zunächst haben wir bestätigt, dass es keine Duplikate in der Liste der Mobiltelefonnummern gibt, und außerdem durch Browser-Debugging bestätigt, dass das Frontend keine wiederholten Anfragen initiiert hat.

Bei der Überprüfung der Protokolle der beiden Server wurde festgestellt, dass wiederholte Sendungen auftraten und die Sendezeitpunkte nicht zur gleichen Zeit lagen.

Anhand der Protokolle kann geschätzt werden, dass die Zeit zum Senden einer Textnachricht 10 Millisekunden beträgt.

Ich habe auch das Verarbeitungs-Timeout-Protokoll im Protokoll überprüft und festgestellt, dass wiederholte Anforderungen auf verschiedenen Computern verarbeitet werden und das Verarbeitungsintervall konsistent ist

A-Protokoll

10:03:05,878  INFO TIMEOUT.info:252 - time: 75701ms, concurrent: 1, url: 
/push/sendmessage.10:07:24,705  INFO TIMEOUT.info:252 - time: 15148ms, concurrent: 0, url: /push/sendmessage.

B-Protokoll

10:03:21,599  INFO TIMEOUT.info:252 - time: 76471ms, concurrent: 1, url: 
/push/sendmessage.10:07:39,718  INFO TIMEOUT.info:252 - time: 15113ms, concurrent: 0, url: /push/sendmessage.

Basierend auf den oben genannten Informationen haben wir vermutet, dass die Ausführungszeit der Anforderung den Grenzwert überschritten hat, was dazu führte, dass die Front-End-Eingabeaufforderung fehlschlug. Doppelte Übermittlungen sollten durch den Wiederholungsmechanismus verursacht werden.

Also kontaktierte ich den Betrieb und die Wartung zur Bestätigung. Relevante Antworten erhalten:

Nginx kann das Timeout konfigurieren, vorausgesetzt, es ist auf 15 Sekunden konfiguriert und die Verarbeitung und Rückgabe einer Anfrage dauert 16 Sekunden. Nginx leitet zur Verarbeitung an Server A weiter. Wenn A bis zur 15. Sekunde ausgeführt wird, sendet Nginx es erneut an den B-Dienst zur Verarbeitung. Das Frontend wartet 30 Sekunden und gibt schließlich einen Fehler zurück. A und B haben jeweils entsprechende Anfragen erhalten und diese intern bearbeitet.

Nachdem Sie den Grund mit den Betriebs- und Wartungsklassenkameraden bestätigt haben, können Sie anhand der relevanten Informationen selbst suchen.

Wiederholungsmechanismus von Nginx

Der Artikel weist auch auf eine Lösung hin, die über IP auf Dienste zugreifen und Nginx umgehen kann.

Darüber hinaus verfügt unsere Website über eine Download-Funktion. Vor der Optimierung war die Ausführungszeit jedes Downloads ebenfalls sehr lang, es gab jedoch kein Timeout-Problem. Analysiert die möglichen Unterschiede zwischen GET und POST. Der folgende Link ist oben ebenfalls angegeben, um die allgemeine Idee zu ermitteln.

http://serverfault.com/questions/528653/how-can-i-stop-nginx-from-retrying-put-or-post-requests-on-upstream-server-timeo

3. Problemübersicht

Durch Online-Informationsreferenz kann Nginx verschiedene Timeout-Strategien für Datei-Upload, Download, GET- und POST-Anfragen festlegen.

Darüber hinaus gibt es für das SMS-Massenversandgeschäft tatsächlich ein separates Modul, das die Konfiguration über Regeln verwaltet und die Offline-Aufgabenausführung durchführt. Das bestehende Massenversandmodul ist nur für Kleinunternehmen gedacht.