Entdecken Sie die Implementierung zuverlässiger Messaging-Dienste

Eine gemeinsame Lösung

Einführung

Verteilte Transaktionen sind oft der Schwachpunkt serviceorientierter Transaktionen, aber es gibt immer noch einige Szenarien, die auf verteilte Transaktionen angewiesen sind

Es gibt viele Möglichkeiten, verteilte Transaktionsprobleme zu lösen, und es gibt viele Blogs im Internet, die verschiedene Lösungen anbieten. Zusammenfassend kann es im Allgemeinen in die folgenden zwei Methoden unterteilt werden: 1. Two-Phase Commit (kurz 2PC): Dies ist eine gängige Lösung für verteilte Transaktionen. Bei dieser Methode ist der Koordinatorknoten dafür verantwortlich, die Vorgänge der Teilnehmerknoten zu koordinieren und sicherzustellen, dass alle Knoten beim Festschreiben oder Zurücksetzen eine Einigung erzielen. Starre verteilte Transaktionen und zweiphasiges Commit sind ein Mechanismus, um eine starke Konsistenz zu erreichen. Starre verteilte Transaktionen beziehen sich auf eine Reihe von Vorgängen, die von mehreren Teilnehmerknoten in einem verteilten System ausgeführt werden und die Atomizität gewährleisten müssen, d. h. entweder alle erfolgreich sind oder alle fehlschlagen. Dieser Mechanismus erfordert, dass alle Teilnehmerknoten während der Transaktionsausführung dem gleichen Protokoll folgen und die Transaktion unter Anleitung des Koordinatorknotens implementieren

Flexible verteilte Transaktionen sind eine Methode zur Verarbeitung von Transaktionen in einem verteilten System. Es verwendet die Best-Effort-Commit-Strategie, das heißt, es versucht sein Bestes, um die Transaktionsübermittlung abzuschließen, lässt aber auch zu, dass einige Vorgänge fehlschlagen. Bei flexiblen verteilten Transaktionen wird normalerweise der TCC-Modus (Try-Confirm-Cancel) verwendet, um das Transaktionsmanagement zu implementieren. Das TCC-Modell zerlegt Transaktionen in drei Phasen: Versuchen, Bestätigen und Abbrechen

Lösen Sie zunächst die Voraussetzungsgarantie für verteilte Transaktionen: Die Schnittstelle muss idempotent sein, um zu verhindern, dass das wiederholte Senden von Nachrichten das Geschäft beeinträchtigt.

2 Zuverlässiges Messaging-Systemdesign (das fühlt sich gut an und ist relativ einfach, also werde ich es teilen)

Wie oben gezeigt

Ausführung starten. Zum Beispiel:

versuchen{

if(prepare()) { //Vorsendephase

doService(); //Geschäftslogik ausführen
updateMsgStatus();//Nachricht aktualisieren, um den Status zu bestätigen }
}


1 Testphase vor dem Senden der Nachricht: Wenn das Vorsenden der Nachricht fehlschlägt, wurde das Geschäft noch nicht ausgeführt, sodass die Systeme A und B immer noch konsistent sind und keine Verarbeitung erforderlich ist
Das ist leicht zu verstehen

2 Die zuvor gesendete Nachricht ist erfolgreich und die Geschäftslogik wird ausgeführt. Wenn die Ausführung erfolgreich ist, wird der Status der aktualisierten, zuvor gesendeten Nachricht in „Versand bestätigt“ geändert. Wenn die Ausführung der Geschäftslogik zu diesem Zeitpunkt fehlschlägt, wird die zuvor gesendete Nachricht nicht mit dem neuen Status aktualisiert. Zu diesem Zeitpunkt beginnt das Nachrichtenbestätigungssystem zu arbeiten und kehrt zum Geschäftssystem 1 zurück, um den Nachrichtenstatus zu überprüfen. Wenn festgestellt wird, dass die Geschäftsausführung fehlgeschlagen ist, wird der Status vor dem Senden auf den Status „Fehlgeschlagen“ aktualisiert.

3 Wenn zu diesem Zeitpunkt die Geschäftsausführung erfolgreich ist und die Nachricht aktualisiert wird, um den Versand zu bestätigen, ist sie in Ordnung und perfekt. Wenn die Nachrichtenaktualisierung fehlschlägt, prüft das Nachrichtenbestätigungssystem trotzdem den Status und aktualisiert, ob die Nachricht gelöscht oder zum Senden bestätigt wurde.

4 Messager beginnen zu konsumieren

1> Wenn beispielsweise der Verbrauch fehlschlägt und Inkonsistenzen auftreten, erkennt das Nachrichtenwiederherstellungssystem den Nachrichtenstatus und sendet die Nachricht erneut

2>Wenn die Ausführung des Geschäfts fehlschlägt, wird die Nachricht nicht bestätigt. Das Nachrichtenwiederherstellungssystem erkennt weiterhin den Nachrichtenstatus und sendet die Nachricht erneut

3> Wenn die Anfrage fehlschlägt, sollte die obige Logik zum erneuten Senden des Einspruchs verwendet werden. Natürlich gibt es eine Begrenzung für die Anzahl der erneuten Sendungen. Sie kann nicht immer gesendet werden gelangt in die Warteschlange für unzustellbare Nachrichten und wartet auf manuelles Eingreifen

4> Wenn die Anfrage erfolgreich ist, wird die Nachricht erfolgreich verarbeitet, was perfekt ist und das Problem eines zuverlässigen Nachrichtendienstes löst

Drei, arbeite hart, um einzureichen

Dies ist relativ einfach. Fehlgeschlagene Nachrichten werden wiederholt übermittelt, um in einigen Szenarien mit schwacher Echtzeitleistung einen erfolgreichen Nachrichten-Push sicherzustellen.

Zum Beispiel: Senden Sie eine Nachricht an einen Drittanbieter, wenn eine Transaktion abgeschlossen ist. Sie können zu diesem Zeitpunkt eine harte Unterwerfung verwenden

Der Artikel wurde von der Open Source China Community [http://www.oschina.net] abgedruckt.

Das obige ist der detaillierte Inhalt vonEntdecken Sie die Implementierung zuverlässiger Messaging-Dienste. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!