Komplexität bei der Implementierung des SAGA-Musters? ⇐ Java

[Guest]

System: Ich habe zwei Bestelldienste (separate DBs), der erste ist der Dienst Benutzerbestellung, Benutzeroperationen wie „Place-Order“, „Get-Order“, Stornierung, Rückgabe usw. werden hier durchgeführt, und zweitens gibt es den Service Verkäufer-Bestellung, der den Bestellstatus von „Versandt“ bis „Geliefert“ steuert. Der Bestellstatus wird hier basierend auf den Aktionen des Verkäufers oder des Zustellers aktualisiert, z. B. „Versand durch“. Verkäufer, Stornierung durch Verkäufer, geliefert durch Agent usw.
Problem: Wir möchten dem Benutzer die Möglichkeit geben, eine Bestellung per Nachnahme (Nachnahme) im Voraus zu bezahlen, sofern diese nicht storniert wird durch Benutzer oder Verkäufer, Versand durch Verkäufer. (Zukünftig können je nach Anwendungsfall weitere Bedingungen hinzugefügt werden, um die Kriterien für die Berechtigung zur Vorauszahlung zu bestimmen.)
Da es sich bei der Benutzerzahlung um eine Benutzeraktion handelt, ist dies auch der Fall wird im Benutzerauftragsdienst initiiert. Diese Aktion kann jedoch nicht bestätigt werden, bevor der aktuelle Status der Bestellung mit dem Verkäufer-Bestellservice (storniert oder versendet) und mit dem Benutzer-Bestellservice (storniert) überprüft wird.
Vorgänge wie Stornierung und Prepaid-Bestellkonvertierung müssen isoliert erfolgen, z. B. - Der Benutzer kann die Bestellung stornieren, während die Umstellung auf Prepaid erfolgt (noch nicht umgestellt) wird. Daher ist es möglich, dass die Bestellung storniert wird, ohne dass dem Benutzer Geld zurückerstattet wird, da die Zahlungsart der Bestellung zum Zeitpunkt der Stornierung und später noch festgelegt wurde wurde auf Prepaid umgestellt, daher müssen Vorgänge wie diese isoliert erfolgen.
Lösen:
Verwenden von SAGA zur verteilten Implementierung Transaktion. Warum verteilt – da wir zwei Bestelldienste haben und beide bestätigen müssen, dass der Zahlungsmodus der Bestellung in Prepaid umgewandelt werden kann, wird dann nur der Zahlungsmodus in Prepaid umgewandelt.
Implementierungsablauf< /strong>: Der Benutzer initiiert die Umstellung des Zahlungsmodus über den Benutzer-Bestelldienst. Wenn die Bestellung bereits storniert wurde, schlägt die Zahlungsinitiierung fehl, andernfalls wird eine Benutzer-Stornierungssperre benötigt (um sicherzustellen, dass die Stornierung nicht durchgeführt werden sollte, während die Bestellung in eine Prepaid-Bestellung umgewandelt wird). dann veröffentlicht es a check-event, seller-order hört dieses Ereignis ab, nimmt die Stornierung durch den Verkäufer und die Versandsperre entgegen, prüft dann, ob der Bestellstatus für die Prepaid-Konvertierung in seller-order infrage kommt (z. B. sollte der Status nicht versendet oder storniert werden), dann wird bestätigt und veröffentlicht ein Antwortereignis mit Erfolg (Bestellung kann in Prepaid umgewandelt werden) oder Fehler (Bestellung kann nicht in Prepaid umgewandelt werden, könnte daran liegen, dass sie bereits versandt oder vom Verkäufer storniert wurde), Benutzer-Bestellung behält die Sperre und überwacht das Antwort-Rückereignis trifft Entscheidung um die Bestellung erfolgreich in eine Prepaid-Bestellung umzuwandeln oder sie abzulehnen und mit der Benutzerrückerstattung basierend auf dem Status des Antwortereignisses fortzufahren.
Zur Implementierung oben mit SAGA. Es gibt ein paar Dinge, die ich auf der Serverseite erledigen muss.

• Sperrimplementierung – Um eine Sperre zu implementieren, können wir sie erstellen ein Eintrag in der Tabelle mit dem Status BEARBEITUNG Prepaid-Zahlung für eine Bestellung. Dieser Status bedeutet, dass die Umstellung der Bestellung in Prepaid begonnen, aber noch nicht bestätigt wurde. Basierend auf dem Status des Eintrags können wir eine Stornierungsanforderung ablehnen, bis der Status VERARBEITUNG in einen beliebigen Endstatus verschoben wird – FEHLGESCHLAGEN oder ERFOLGREICH. Auf die gleiche Weise wird eine Sperre für den Verkäufer-Bestellservice implementiert, um den Versand abzulehnen oder durch den Verkäufer zu stornieren.

• Hier 2 Es sind Dienste beteiligt, daher müssen wir diese beiden Dienste sperren. Aber was wäre, wenn mehrere Dienste beteiligt wären, die zustimmen müssen, um die Zahlung erfolgreich zu bestätigen? In diesem Fall müssen wir dies für alle Dienste implementieren, was Teil der Sperre wird. Dies scheint überflüssig zu sein, da mehr Dienste involviert sind. Jeder einzelne wird über eine Sperrtabelle verfügen, um die Initiierung anderer Transaktionen zu stoppen, während einer ausgeführt wird.
• Die Vorauszahlung der Bestellung ist eine SAGA. Es besteht die Möglichkeit, mehrere SAGAs in einem Dienst zu initiieren und erst nach der Bestätigung aller umliegenden Dienste bestätigt zu werden, für jede neue SAGA, die wir erstellen müssen eine separate Tabelle für alle Dienste, die wiederum redundant ist.
• Sperrtabellen sind temporär, da die darin enthaltenen Daten keinen Nutzen mehr haben, sobald sie ihren Zweck erfüllen, und primäre Informationen, ob es sich um eine Bestellung im Voraus oder per Nachnahme handelt, verbraucht werden aus primären Bestelltabellen, daher müssen wir weiterhin Daten in diesen Tabellen löschen, indem wir regelmäßig einen Job ausführen.

Gibt es hier eine bessere Möglichkeit, Sperren zu erstellen, die die Isolation untereinander gewährleisten? Transaktionen?

• Langlebige Sperren – Sobald eine Sperre erworben wurde Bei einem Dienst kann er erst dann freigegeben werden, wenn er von allen seinen nachgelagerten Diensten eine Antwort erhält, was vereinbart werden muss.
  Der Benutzer-Bestelldienst bleibt gesperrt, bis er eine Antwort vom Verkäufer-Bestelldienst erhält, also bis dahin alle anderen Transaktionen( Vorgänge wie die Benutzerstornierung müssen warten, bis die Prepaid-Konvertierungssperre aufgehoben wird Alle Dienste) werden für immer gesperrt, und der Benutzer wartet auch weiterhin darauf, den endgültigen Status der Bestellung zu erfahren – ob sie konvertiert wurde oder nicht.
  Das Setzen einer Sperre mit Timer könnte hier zu einer Inkonsistenz des Systems führen – z. B. wenn Innerhalb von 15 Minuten kommt das Antwortereignis nicht vom Verkäufer-Bestelldienst zurück. Wir geben die Sperre im Benutzer-Bestelldienst frei. Was aber, wenn die Bestellung im Verkäufer-Bestelldienst erfolgreich in Prepaid umgewandelt wird, werden alle Sperren aufgehoben (z. B. die Versandsperre). , nach dass der Verkäufer die Bestellung als Vorauszahlung versendet. User-Order erhält in der 16. Minute ein Antwortereignis, aber jetzt lehnt der User-Order-Dienst es ab, da er die Sperre in der 15. Minute aufgehoben hat. Daher werden die Daten im Verkäufer-Bestellungsservice inkonsistent und bis wir eine Ausgleichsaktion im Verkäufer-Bestellungsdienst ausführen (die die Bestellung von Prepaid zurück in den Nachnahme-Zahlungsmodus umwandelt), könnten Vorgänge mit inkonsistenten Daten in stattgefunden haben Verkäufer-Bestellservice.

Gibt es eine Möglichkeit, Sperren in SAGA zeitbegrenzt zu machen, sodass der Kunde dies nicht tun muss? warten, bis alle abhängigen Systeme wiederhergestellt sind nach einem Fehler grundsätzlich die Zwischentransaktionen (bei denen einige Systeme aktualisiert werden, aber nicht alle Systeme aktualisiert) zwangsweise abbrechen, ohne dass Systemdaten zu irgendeinem Zeitpunkt inkonsistent werden?
< /blockquote>