Wie gehe ich mit asynchronen Warteschlangenfehlern um?

Das ist alles, wir haben ein öffentliches Konto-Tool erstellt. Benutzergruppe A hat die Möglichkeit, Vorlagennachrichten in Gruppen zu senden, und Benutzergruppe B kann Vorlagennachrichten empfangen.

Nachdem Benutzer A den Inhalt auf der Seite ausgefüllt und übermittelt hat, kann es sehr lange dauern, da er in großen Mengen gesendet wird. Daher haben wir eine asynchrone Verarbeitung implementiert, bei der alle Nachrichten des Benutzers in eine Warteschlange verschoben und zurückgegeben werden nachdem der Push für Benutzer A erfolgreich war. Der Front-End-Vorgang von Benutzer A ist beendet.

Danach scannt der Hintergrund die Warteschlange jedes Mal. Wenn sich Daten in der Warteschlange befinden, wird ein Massen-Push durchgeführt.

Jetzt gibt es ein solches Problem, das auf dem offiziellen Konto auftritt (manchmal API-Änderungen, manchmal Server-50X-Fehler), was dazu führt, dass der Warteschlangen-Push auf meiner Seite fehlschlägt. Glücklicherweise können Netzwerk-Timeouts oder vorübergehende Fehler durch geplante Wiederholungsversuche behoben werden.

Aber wenn die Server-API auf diese Weise ersetzt wird, schlägt unser Push zu 100 % fehl und Benutzergruppe B wird die Nachricht nie erhalten. Dieser Fehler kann jedoch nicht von Benutzer A gesehen werden, der denkt, dass der Vorgang erfolgreich war (weil er wurde auf asynchron geändert, der Push endet, wenn er in die Warteschlange gestellt wird, und Sie können nicht weiter auf diese große Push-Liste starren, es kann sehr lange dauern)

Daher möchte ich fragen, ob es eine Designlösung gibt, die Benutzer A darauf aufmerksam machen kann, dass ein Problem mit dem offiziellen Kontoserver vorliegt, wenn es ein Problem mit dem offiziellen Konto-API-Server gibt.

Ich habe darüber nachgedacht, den Status der Push-Liste Benutzer A offenzulegen. Benutzer A kann den Status des Pushs selbst sehen. Es fühlt sich jedoch nicht intuitiv an und Benutzer A sieht sich diese Liste möglicherweise nicht an.

Antwortinhalt:

Das ist alles, wir haben ein öffentliches Konto-Tool erstellt. Benutzergruppe A hat die Möglichkeit, Vorlagennachrichten in Gruppen zu senden, und Benutzergruppe B kann Vorlagennachrichten empfangen.

Nachdem Benutzer A den Inhalt auf der Seite ausgefüllt und übermittelt hat, kann es sehr lange dauern, da er in großen Mengen gesendet wird. Daher haben wir eine asynchrone Verarbeitung implementiert, bei der alle Nachrichten des Benutzers in eine Warteschlange verschoben und zurückgegeben werden nachdem der Push für Benutzer A erfolgreich war. Der Front-End-Vorgang von Benutzer A ist beendet.

Danach scannt der Hintergrund die Warteschlange jedes Mal. Wenn sich Daten in der Warteschlange befinden, wird ein Massen-Push durchgeführt.

Jetzt gibt es ein solches Problem, das auf dem offiziellen Konto auftritt (manchmal API-Änderungen, manchmal Server-50X-Fehler), was dazu führt, dass der Warteschlangen-Push auf meiner Seite fehlschlägt. Glücklicherweise können Netzwerk-Timeouts oder vorübergehende Fehler durch geplante Wiederholungsversuche behoben werden.

Aber wenn die Server-API auf diese Weise ersetzt wird, schlägt unser Push zu 100 % fehl und Benutzergruppe B wird die Nachricht nie erhalten. Dieser Fehler kann jedoch nicht von Benutzer A gesehen werden, der denkt, dass der Vorgang erfolgreich war (weil er wurde auf asynchron geändert, der Push endet, wenn er in die Warteschlange gestellt wird, und Sie können nicht weiter auf diese große Push-Liste starren, es kann sehr lange dauern)

Daher möchte ich fragen, ob es eine Designlösung gibt, die Benutzer A darauf aufmerksam machen kann, dass ein Problem mit dem offiziellen Kontoserver vorliegt, wenn es ein Problem mit dem offiziellen Konto-API-Server gibt.

Ich habe darüber nachgedacht, den Status der Push-Liste Benutzer A offenzulegen. Benutzer A kann den Status des Pushs selbst sehen. Es fühlt sich jedoch nicht intuitiv an und Benutzer A sieht sich diese Liste möglicherweise nicht an.

Ist diese Lösung nicht unvernünftig? Selbst wenn Benutzer A die Ausnahmeinformationen erhält, sind Sie immer noch derjenige, der das Problem behandelt. Warum sollten Sie meiner Meinung nach das Problem des Servers lösen? API zuerst?

Fehlerprotokoll schreiben.