Fassen Sie 7 Lösungen für verteilte Transaktionen zusammen (Theorie + Lösungen)

Mit der rasanten Geschäftsentwicklung und der zunehmenden Komplexität des Geschäfts wird sich das System fast jedes Unternehmens von monolithisch zu verteilt entwickeln, insbesondere zur Microservices-Architektur. Dann werden Sie unweigerlich auf das Problem verteilter Transaktionen stoßen.

In diesem Artikel werden zunächst die relevanten Grundtheorien vorgestellt, dann die klassischsten Transaktionslösungen zusammengefasst und schließlich Lösungen für die Ausführung von Untertransaktionen außerhalb der Reihenfolge (Idempotenz, Nullkompensation und Hängeprobleme) bereitgestellt, die mit allen geteilt werden .

Grundlegende Theorie

Bevor wir die spezifische Lösung erläutern, wollen wir zunächst die grundlegenden theoretischen Kenntnisse verstehen, die mit verteilten Transaktionen verbunden sind.

Nehmen wir die Überweisung als Beispiel: A muss 100 Yuan an B überweisen, dann muss der Restbetrag an A -100 Yuan betragen und der Restbetrag an B +100 Yuan. Die gesamte Überweisung muss sicherstellen, dass A-100 Yuan beträgt +100 sind gleichzeitig erfolgreich, oder beide sind fehlgeschlagen. Sehen wir uns an, wie dieses Problem in verschiedenen Szenarien gelöst wird.

Transaktion

Die Funktion, mehrere Anweisungen als Ganzes auszuführen, wird als Datenbanktransaktion bezeichnet. Datenbanktransaktionen stellen sicher, dass alle Vorgänge im Rahmen der Transaktion entweder erfolgreich sein oder fehlschlagen können.

Transaktionen haben 4 Eigenschaften: Atomizität, Konsistenz, Isolation und Haltbarkeit. Diese vier Eigenschaften werden oft als ACID-Eigenschaften bezeichnet.

• Atomizität (Atomizität): Alle Vorgänge in einer Transaktion sind entweder vollständig abgeschlossen oder nicht abgeschlossen und enden nicht in einer Zwischenverbindung. Wenn während der Ausführung der Transaktion ein Fehler auftritt, wird der Zustand vor Beginn der Transaktion wiederhergestellt, als ob die Transaktion nie ausgeführt worden wäre.
• Konsistenz: Die Integrität der Datenbank wird vor Beginn der Transaktion und nach Ende der Transaktion nicht beeinträchtigt. Die Integrität einschließlich Fremdschlüsseleinschränkungen, anwendungsdefinierter Einschränkungen usw. wird nicht zerstört.
• Isolation: Die Datenbank ermöglicht mehreren gleichzeitigen Transaktionen das gleichzeitige Lesen, Schreiben und Ändern ihrer Daten. Durch die Isolation können Dateninkonsistenzen aufgrund von Kreuzausführungen verhindert werden, wenn mehrere Transaktionen gleichzeitig ausgeführt werden.
• Dauerhaftigkeit: Nach Abschluss der Transaktion ist die Änderung der Daten dauerhaft und geht auch bei einem Systemausfall nicht verloren.

Wenn unser Geschäftssystem nicht kompliziert ist und wir die Daten ändern und die Übertragung in einer Datenbank und einem Dienst abschließen können, können wir Datenbanktransaktionen verwenden, um den korrekten Abschluss des Übertragungsgeschäfts sicherzustellen.

Verteilte Transaktionen

Banküberweisungen sind ein typisches Szenario für verteilte Transaktionen. Angenommen, A muss Geld an B überweisen, wobei die ACID der Überweisung nicht durch eine lokale Transaktion garantiert werden kann eine Datenbank. Gelöst durch verteilte Transaktionen.

Verteilte Transaktion bedeutet, dass sich der Initiator der Transaktion, der Ressourcen- und Ressourcenmanager sowie der Transaktionskoordinator auf verschiedenen Knoten des verteilten Systems befinden. Im oben genannten Transfergeschäft befinden sich der Betrieb von Benutzer A-100 und der Betrieb von Benutzer B+100 nicht auf demselben Knoten. Im Wesentlichen sollen verteilte Transaktionen die korrekte Ausführung von Datenoperationen in verteilten Szenarien sicherstellen.

Verteilte Transaktionen in einer verteilten Umgebung, um die Anforderungen an Verfügbarkeit, Leistung und Downgrade-Dienste zu erfüllen und die Anforderungen an Konsistenz und Isolation zu reduzieren, folgen einerseits der BASE-Theorie (BASE-bezogene Theorie, die viele umfasst). Inhalt, interessierte Studenten können sich auf die BASE-Theorie beziehen):

• Grundlegende Geschäftsverfügbarkeit (Basic Availability)
• Soft State (Soft State)
• Eventuelle Konsistenz (Eventuelle Konsistenz)

In ähnlicher Weise folgen auch verteilte Transaktionen teilweise der ACID-Spezifikation:

• Atomizität: strikt eingehalten
• Konsistenz: Die Konsistenz nach Abschluss der Transaktion kann entsprechend gelockert werden
• Isolation: Parallele Transaktionen können nicht beeinträchtigt werden; die Sichtbarkeit von Zwischentransaktionsergebnissen ermöglicht eine sichere Entspannung
• Haltbarkeit: Befolgen Sie strikt die

Lösung für verteilte Transaktionen

Aufgrund der Lösung für verteilte Transaktionen kann keine vollständige ACID-Garantie erreicht werden, und es gibt keine perfekte Lösung, die alle Geschäftsprobleme lösen kann. Daher wird in tatsächlichen Anwendungen die am besten geeignete verteilte Transaktionslösung basierend auf den unterschiedlichen Merkmalen des Unternehmens ausgewählt.

Zwei-Phasen-Commit/XA

XA ist eine von der X/Open-Organisation vorgeschlagene verteilte Transaktionsspezifikation. Die XA-Spezifikation definiert hauptsächlich die Beziehung zwischen dem (globalen) Transaktionsmanager (TM) und dem (lokalen) Ressourcenmanager (RM). )-Schnittstelle. Lokale Datenbanken wie MySQL spielen in XA die Rolle von RM.

Wenn der Teilnehmer bereit ist, meldet er TM, dass er bereit ist.

Derzeit unterstützen Mainstream-Datenbanken grundsätzlich XA-Transaktionen, einschließlich MySQL, Oracle, SQLServer und Postgre.

XA-Transaktionen bestehen aus einem oder mehreren Ressourcenmanagern (RM), einem Transaktionsmanager (TM) und einer Anwendung (ApplicationProgram).

Die drei Rollen RM, TM und AP sind hier klassische Rollenaufteilungen, die in den nachfolgenden Saga-, Tcc- und anderen Transaktionsmodi verwendet werden.

Nehmen Sie die obige Übertragung als Beispiel. Ein erfolgreich abgeschlossenes XA-Transaktionssequenzdiagramm sieht wie folgt aus:

Wenn ein Teilnehmer die Vorbereitung versäumt, benachrichtigt TM alle Teilnehmer, die die Vorbereitung abgeschlossen haben, zum Rollback.

Die Merkmale von Java, C#, Node usw. können auf DTM verweisen

SAGA
• Saga ist eine Lösung, die von Sagas in diesem Datenbankpapier erwähnt wird. Die Kernidee besteht darin, eine lange Transaktion in mehrere lokale kurze Transaktionen aufzuteilen, die vom Saga-Transaktionskoordinator koordiniert werden. Wenn sie normal endet, wird sie normal abgeschlossen. Wenn ein Schritt fehlschlägt, wird die Kompensationsoperation einmal in umgekehrter Reihenfolge aufgerufen.
• Am Beispiel der obigen Übertragung sieht ein erfolgreich abgeschlossenes SAGA-Transaktionssequenzdiagramm wie folgt aus:

Hohe Parallelität, keine Notwendigkeit, Ressourcen für eine lange Zeit wie bei XA-Transaktionen zu sperren.

Der Artikel enthält viele SAGA-Inhalte, darunter zwei Wiederherstellungsstrategien, einschließlich der gleichzeitigen Ausführung von Filialtransaktionen. Unsere Diskussion hier umfasst nur die einfachsten SAGA
• SAGA ist anwendbar. Es gibt viele Szenarien, es eignet sich für lange Transaktionen und es eignet sich für Geschäftsszenarien, die nicht empfindlich auf Zwischenergebnisse reagieren.
• Wenn Leser SAGA weiter studieren möchten, können sie sich auf den DTM beziehen Enthält Beispiele für SAGA-Erfolgs- und -Fehler-Rollbacks sowie verschiedene Netzwerkanomalien.
• TCC

Das Konzept von TCC (Try-Confirm-Cancel) wurde erstmals von Pat Helland in einem 2007 veröffentlichten Artikel mit dem Titel „Life beyond Distributed Transactions: an Apostate’s Opinion“ vorgeschlagen.

TCC ist in 3 Phasen unterteilt

Nehmen Sie die obige Überweisung als Beispiel. Normalerweise wird der Betrag in „Try“ eingefroren, aber nicht abgezogen. Der Betrag wird in „Stornieren“ abgezogen. Ein erfolgreich abgeschlossenes TCC-Transaktionssequenzdiagramm sieht wie folgt aus
• TCC Die Geschäftslogik der Phase „Bestätigen/Abbrechen“ lässt keine Rückgabe eines Fehlers zu. Wenn aufgrund von Netzwerk- oder anderen vorübergehenden Fehlern kein Erfolg zurückgegeben werden kann, wird TM es erneut versuchen, bis „Bestätigen/Abbrechen“ einen Erfolg zurückgibt.
• TCC-Funktionen sind wie folgt:

Die Konsistenz ist besser und es wird keine Situation geben, in der SAGA das Geld abgezogen hat und es dann nicht überwiesen hat.

TCC eignet sich für Unternehmen mit Auftragstyp, Unternehmen mit Einschränkungen bei Zwischenstaaten Wenn Sie sich weiter mit TCC befassen möchten, können Sie sich auf die

Local Message Table

beziehen. Diese Lösung war ursprünglich ein Artikel, den der eBay-Architekt Dan Pritchett 2008 an ACM veröffentlichte. Der Kern des Entwurfs besteht darin, die asynchrone Ausführung von Aufgaben sicherzustellen, die eine verteilte Verarbeitung durch Nachrichten erfordern.
• Der allgemeine Prozess ist wie folgt:
• Das Zusammenfassen lokaler Nachrichten und Geschäftsvorgänge in einer Transaktion gewährleistet die Atomizität des Geschäfts- und Nachrichtenversands. Entweder sind sie alle erfolgreich oder sie scheitern.

Wenn die Transaktion zum Abzug des Kontostands fehlschlägt, wird die Transaktion ohne weitere Schritte direkt zurückgesetzt.

Wenn die Meldung zur Produktion der Radsequenz fehlschlägt und die Transaktion zur Erhöhung des Kontostands fehlschlägt, wird sie erneut versucht.

• Wenn der Verbraucher Wenn die Logik beim erneuten Versuch nicht erfolgreich ist, sind weitere Mechanismen erforderlich, um Vorgänge zurückzusetzen. Anwendbar auf Unternehmen, die asynchron ausgeführt werden können und für nachfolgende Vorgänge kein Rollback erforderlich ist

  Transaktionsnachricht

  In der oben genannten lokalen Nachrichtentabellenlösung muss der Produzent eine zusätzliche Nachrichtentabelle erstellen und die lokale Nachrichtentabelle abfragen, was eine hohe Geschäftsbelastung mit sich bringt. Alibabas Open-Source-RocketMQ 4.3 und höher unterstützt offiziell Transaktionsnachrichten. Diese Transaktionsnachricht platziert im Wesentlichen die lokale Nachrichtentabelle auf RocketMQ, um das Atomizitätsproblem des Nachrichtenversands und der lokalen Transaktionsausführung auf der Produktionsseite zu lösen.

  Senden und Senden von Transaktionsnachrichten:

  • Senden Sie eine Nachricht (halbe Nachricht)
  • Der Server speichert die Nachricht und reagiert auf das Schreibergebnis der Nachricht
  • Führen Sie lokale Transaktionen basierend auf dem Sendeergebnis aus (wenn das Schreiben fehlschlägt, Die Halbnachricht lautet: Das Unternehmen ist nicht sichtbar und die lokale Logik wird nicht ausgeführt Das normale Senden ist wie folgt:

  Vergütungsprozess:

  Für Transaktionsnachrichten ohne Commit/Rollback (Nachrichten im Status „Ausstehend“) initiieren Sie eine „Überprüfung“ vom Server. Der Produzent empfängt die Überprüfungsnachricht und gibt den Status der zurück Lokale Transaktion, die der Nachricht entspricht, nämlich Commit oder Rollback. Die Transaktionsnachrichtenlösung ist dem lokalen Nachrichtentabellenmechanismus sehr ähnlich. Der Hauptunterschied besteht darin, dass die ursprünglichen zugehörigen lokalen Tabellenoperationen durch eine umgekehrte Abfrageschnittstelle ersetzt werden Die Anzahl der Transaktionsnachrichten lautet wie folgt:

  Lange Transaktionen müssen nur in mehrere Aufgaben aufgeteilt werden und es wird eine einfach zu verwendende umgekehrte Abfrageschnittstelle bereitgestellt.

  
  Wenn die Verbraucherlogik den Wiederholungsversuch nicht besteht, sind weitere Mechanismen zum Zurücksetzen erforderlich Der Vorgang
  

  Anwendbar für Unternehmen, die asynchron ausgeführt werden können und für nachfolgende Vorgänge kein Rollback erforderlich ist

  Wenn Leser, die Transaktionsnachrichten weiter studieren möchten, sich auf DTM oder Rocketmq beziehen können
  • Best Effort Notification
  • Die initiierende Benachrichtigungspartei nutzt einen bestimmten Mechanismus, um den Empfänger nach besten Kräften über die Ergebnisse der Geschäftsverarbeitung zu informieren. Dazu gehört insbesondere:

  Es gibt einen bestimmten Benachrichtigungsmechanismus für die Wiederholung von Nachrichten. Da die Partei, die die Benachrichtigung erhält, die Benachrichtigung möglicherweise nicht erhält, muss ein bestimmter Mechanismus vorhanden sein, um die Nachricht wiederholt zu benachrichtigen.

  Mechanismus zum Korrekturlesen von Nachrichten. Wenn der Empfänger trotz aller Bemühungen nicht benachrichtigt wird oder wenn der Empfänger die Nachricht nach dem Konsum erneut konsumieren möchte, kann der Empfänger den Benachrichtiger aktiv nach Nachrichteninformationen fragen, um den Bedarf zu decken.

  Die zuvor eingeführte lokale Nachrichtentabelle und die Transaktionsnachrichten sind beide zuverlässige Nachrichten. Wie unterscheiden sie sich von der hier vorgestellten Best-Effort-Benachrichtigung?

  Zuverlässige Nachrichtenkonsistenz. Die initiierende Benachrichtigungspartei muss sicherstellen, dass die Nachricht gesendet und an die empfangende Benachrichtigungspartei gesendet wird. Der Schlüssel zur Zuverlässigkeit der Nachricht liegt in der Verantwortung der initiierenden Benachrichtigungspartei.

  Best-Effort-Benachrichtigung: Die initiierende Partei versucht ihr Bestes, um die empfangende Benachrichtigungspartei über die Ergebnisse der Geschäftsverarbeitung zu informieren. Zu diesem Zeitpunkt muss die empfangende Benachrichtigungspartei jedoch möglicherweise die Schnittstelle der initiierenden Benachrichtigung aktiv aufrufen Partei, die die Ergebnisse der Geschäftsabwicklung abfragt, und die Benachrichtigung. Der Schlüssel zur Zuverlässigkeit ist die Partei, die die Benachrichtigung erhält.

  In Bezug auf die Lösung erfordert die Best-Effort-Benachrichtigung:
  
  

  Stellen Sie eine Schnittstelle bereit, damit der Empfänger der Benachrichtigung die Ergebnisse der Geschäftsverarbeitung über die Schnittstelle abfragen kann.
  Nachrichtenwarteschlangen-ACK-Mechanismus, die Nachrichtenwarteschlange basiert auf dem Intervall von 1 Minute, 5 Minuten, 10 Minuten, 30 Minuten, 1 Stunde, 2 Stunden, 5 Stunden und 10 Stunden und erhöhen Sie das Benachrichtigungsintervall schrittweise, bis die Obergrenze des für die Benachrichtigung erforderlichen Zeitfensters erreicht ist. Keine weiteren Benachrichtigungen mehr

  Best-Effort-Benachrichtigungen eignen sich für geschäftliche Benachrichtigungstypen. Beispielsweise werden die Ergebnisse von WeChat-Transaktionen jedem Händler über Best-Effort-Benachrichtigungen mitgeteilt. Es gibt sowohl Rückrufbenachrichtigungen als auch Transaktionsabfrageschnittstellen

  AT-Transaktionsmodus
  • Dies ist ein Transaktionsmodell in Alibabas Open-Source-Projekt. Seata wird in Ant Financial auch FMT genannt. Der Vorteil besteht darin, dass der Transaktionsmodus auf ähnliche Weise wie der XA-Modus verwendet wird. Das Unternehmen muss keine verschiedenen Kompensationsvorgänge schreiben und der Rollback wird vom Framework automatisch abgeschlossen. Der Nachteil ist auch der von XA -Term-Sperren, die nicht für Szenarien mit hoher Parallelität geeignet sind. Aus Leistungssicht ist der AT-Modus höher als der XA, bringt aber auch neue Probleme wie Dirty Rollback mit sich. Interessierte Studenten können sich auf Seata-AT beziehen
  • Ausnahmebehandlung
  In allen Aspekten verteilter Transaktionen können Probleme wie Netzwerk- und Geschäftsausfälle auftreten. Diese Probleme erfordern, dass die Geschäftsseite verteilter Transaktionen anti-rollback und anti ist -Hängen von drei Merkmalen.
  Ausnahmen
  Im Folgenden werden TCC-Transaktionen verwendet, um diese Ausnahmen zu veranschaulichen:

  Leeres Rollback:

  　Die Cancel-Methode der zweiten Stufe wird aufgerufen, ohne die Try-Methode der TCC-Ressource aufzurufen. Die Cancel-Methode muss dies identifizieren leeres Rollback und gibt dann direkt Erfolg zurück.
  　Der Grund dafür ist, dass der Filialtransaktionsaufruf als Fehler aufgezeichnet wird, wenn bei einer Zweigstellentransaktion ein Fehler auftritt zurückgesetzt werden und die zweite Phase wird die Methode „Abbrechen“ aufrufen, wodurch ein leeres Rollback entsteht.

  Idempotenz:

  Da jede Anfrage Netzwerkanomalien und wiederholte Anfragen aufweisen kann, müssen alle verteilten Transaktionszweige Idempotenz sicherstellen

  Suspension:

  Suspension ist für eine Verteilung. In dieser Transaktion ist die Abbruchschnittstelle der zweiten Stufe wird vor der Try-Schnittstelle ausgeführt.

  　Der Grund dafür ist, dass beim RPC-Aufruf der Zweigstellentransaktion zuerst die Zweigstellentransaktion registriert und dann der RPC-Aufruf ausgeführt wird. Wenn das von RPC aufgerufene Netzwerk zu diesem Zeitpunkt überlastet ist, benachrichtigt TM RM nach dem RPC-Timeout Setzen Sie die verteilte Transaktion zurück, was passieren kann. Nach Abschluss des Rollovers erreicht die Try RPC-Anfrage den Teilnehmer und wird tatsächlich ausgeführt.

  Sehen wir uns das Zeitdiagramm einer Netzwerkausnahme an, um die oben genannten Probleme besser zu verstehen
  

  • Bei der Geschäftsverarbeitungsanforderung 4 wird „Abbrechen“ vor „Versuchen“ ausgeführt und ein leeres Rollback muss verarbeitet werden
  • Bei der Geschäftsverarbeitungsanforderung 6 , Abbrechen wird wiederholt ausgeführt und muss idempotent sein Derzeit wird von verschiedenen Unternehmen empfohlen, mithilfe des eindeutigen Schlüssels abzufragen, ob der zugehörige Vorgang abgeschlossen wurde. Bei Abschluss erfolgt eine direkte Erfolgsmeldung. Die entsprechende Beurteilungslogik ist komplex, fehleranfällig und stellt eine hohe Geschäftsbelastung dar.
  • Subtransaktionsbarriere
  Im Projekt https://github.com/yedf/dtm wurde eine Subtransaktionsbarrierentechnologie entwickelt, mit der dieser Effekt erzielt werden kann:
  Alle Diese Anfragen werden nach Erreichen der Untertransaktionsbarriere gefiltert: Normale Anfragen passieren die Barriere. Nachdem Entwickler Subtransaktionsbarrieren verwendet haben, werden alle oben genannten Ausnahmen ordnungsgemäß behandelt, und Geschäftsentwickler müssen sich nur noch auf die eigentliche Geschäftslogik konzentrieren, wodurch die Belastung erheblich reduziert wird.

  Die Untertransaktionsbarriere stellt die Methode ThroughBarrierCall bereit. Der Prototyp der Methode ist:
  

  func ThroughBarrierCall(db *sql.DB, transInfo *TransInfo, busiCall BusiFunc)

  Nach dem Login kopieren
  Geschäftsentwickler können ihre eigene zugehörige Logik in busiCall schreiben und diese Funktion aufrufen. ThroughBarrierCall stellt sicher, dass busiCall in Szenarien wie leerem Rollback und Suspendierung nicht aufgerufen wird, wenn das Unternehmen wiederholt aufgerufen wird. Es gibt eine idempotente Steuerung, um sicherzustellen, dass es nur einmal übermittelt wird.

  Die Subtransaktionsbarriere verwaltet TCC, SAGA, Transaktionsnachrichten usw. und kann auch auf andere Bereiche ausgeweitet werden.
  

  Prinzip der Subtransaktionsbarriere
  Das Prinzip der Subtransaktionsbarrieretechnologie besteht darin, eine Filialtransaktion einzurichten Statustabelle sub_trans_barrier in der lokalen Datenbank, mit einem eindeutigen Schlüssel. Öffnen Sie eine Transaktion für den Zweignamen der globalen Transaktions-ID-Untertransaktions-ID-Untertransaktion (try|confirm|cancel)

  Wenn es sich um einen Try-Zweig handelt, dann einfügen, ignorieren, einfügen, gid-branchid-try, wenn das Einfügen erfolgreich ist, rufen Sie die interne Logik der Barriere auf Logik

  Wenn es sich um den Abbruchzweig handelt, fügen Sie „Ignore“ ein, fügen Sie „gid-branchid-try“ ein und fügen Sie dann „gid-branchid -cancel“ ein. Wenn „try“ nicht eingefügt wurde und „cancel“ erfolgreich eingefügt wurde, rufen Sie die Logik innerhalb der Barriere auf
  • Die Logik innerhalb der Barriere gibt Erfolg zurück, schreibt die Transaktion fest, gibt Erfolg zurück Kompensationskontrolle – wenn Try nicht ausgeführt wird und Cancel direkt ausgeführt wird, wird Cancel erfolgreich in gid-branchid-try eingefügt, ohne die Logik innerhalb der Barriere zu verwenden, wodurch eine leere Kompensationskontrolle gewährleistet wird.
  • Impotente Kontrolle – Es kann kein eindeutiger Schlüssel sein Wird wiederholt in einen beliebigen Zweig eingefügt, um sicherzustellen, dass er nicht wiederholt ausgeführt wird. hängende Kontrolle
  • Es gibt einen ähnlichen Mechanismus für SAGA, Transaktionsnachrichten usw.
  • Zusammenfassung der Subtransaktionsbarriere
  • Die Subtransaktionsbarrierentechnologie ist die erste ihrer Art unter https://github.com/yedf/dtm. Ihre Bedeutung liegt in der Entwicklung einfacher und leicht zu implementierender Algorithmen und der Bereitstellung eines In erster Linie geht es darum, einfache und leicht zu implementierende Algorithmen zu entwerfen und einfache und benutzerfreundliche Schnittstellen bereitzustellen von der Verarbeitung von Netzwerkausnahmen befreit.
  Diese Technologie muss derzeit mit dem Transaktionsmanager yedf/dtm gekoppelt werden. Derzeit wurde das SDK den Entwicklern der Go- und Python-Sprachen zur Verfügung gestellt. SDKs für andere Sprachen sind in Planung. Für andere verteilte Transaktions-Frameworks kann die Technologie gemäß den oben genannten Prinzipien schnell implementiert werden, sofern geeignete verteilte Transaktionsinformationen bereitgestellt werden.
  Zusammenfassung
  • Dieser Artikel stellt einige grundlegende Theorien verteilter Transaktionen vor und erläutert häufig verwendete verteilte Transaktionslösungen. In der zweiten Hälfte des Artikels werden auch die Gründe, Klassifizierungen und eleganten Lösungen für Transaktionsausnahmen angegeben.
  • yedf/dtm unterstützt TCC,
  • yedf/dtm unterstützt Clients in Python, Java, PHP, C#, Node und anderen Sprachen, siehe: SDK für jede Sprache.
  Begrüßen Sie alle, die das https://github.com/yedf/dtm-Projekt besuchen, und geben Sie einen Stern, um es zu unterstützen!