Wichtigste Erkenntnisse 

  • Ziel unserer Binance Ledger-Migration war es, das Hot-Account-Problem unseres früheren relationalen Datenbankservers zu lösen.

  • Eine Krypto-Börse ist rund um die Uhr und an 365 Tagen im Jahr in Betrieb und hat kein Wartungsfenster, das die Nutzung von Hebeln erschwert. Im Gegensatz zu einer regulären Börse, die täglich Pausenzeiten hat.

  • Die Migration zu einem neuen Binance Ledger musste online erfolgen, die Vermögenswerte der Benutzer sicher halten und keinerlei Auswirkungen auf das Geschäft haben, damit das Erlebnis für die Endbenutzer nahtlos blieb.

  • Wir haben uns für eine schrittweise Migrationsstrategie für jedes Konto entschieden, statt für eine auf einmal durchgeführte Umstellungsstrategie wie sie das Tool gh-ost verwendet.

Erfahren Sie mehr über unsere Binance Ledger-Migration und die während des gesamten Prozesses verwendeten Tools und Techniken.

Binance Ledger bildet die Grundlage unserer technischen Abläufe und verarbeitet täglich Millionen von Transaktionen über eine riesige Benutzerbasis. Weitere Informationen zum System, seinen Zielen und seinen Herausforderungen finden Sie in unserem Blog „Wie Binance Ledger Ihr Binance-Erlebnis unterstützt“. Unser Migrationsprozess von der alten zur neuen Version stand vor einer typischen Herausforderung: Wie konnten wir den Motor im laufenden Betrieb aktualisieren, während das Flugzeug noch in der Luft ist? Wir mussten die Vermögenswerte unserer Benutzer migrieren, und die Sicherstellung der Sicherheit der Gelder war unsere oberste Priorität.

Die wichtigsten Migrationsherausforderungen für Binance

Um unsere gesetzten Ziele zu erreichen, mussten wir die folgenden Herausforderungen bewältigen:

  1. Sicherstellung der vollständigen Richtigkeit des neuen Ledgers

  2. Erkennen Sie jedes Fondsproblem und beheben Sie es rechtzeitig und präzise

  3. Keine Ausfallzeiten für Upstreams

Vergleich unserer Migrationsmission mit der Online-Datenbank DDL

Bevor wir uns in die Details unserer Lösung vertiefen, schauen wir uns das allgemeine Problem an, das bei der Durchführung einer Online-DDL (Data Definition Language) für eine große Tabelle auftritt. Was genau ist DDL? Stellen Sie sich eine Tabelle mit Hunderten Millionen Zeilen vor, der wir eine weitere Spalte hinzufügen müssen. Wir möchten dies online und ohne Unterbrechung des Geschäftsbetriebs tun.

Zur Lösung dieses Problems wird häufig das Tool „gh-ost“ verwendet. Im folgenden Diagramm können Sie sehen, wie es funktioniert.

Der Prozess besteht im Wesentlichen aus zwei Phasen:

  1. Die Synchronisierungsphase, die so lange fortgesetzt wird, bis die neue Tabelle vollständig mit der Originaltabelle identisch ist. Es müssen zwei Arten von Daten synchronisiert werden:

    1. Existierende Daten

    2. Inkrementelle Daten (neue Daten, die während des laufenden Migrationsprozesses aus der Originaltabelle generiert werden) 

  2. In der Umstellungsphase wird die ursprüngliche Tabelle durch die neue ersetzt, ohne laufende Transaktionen zu unterbrechen.

Wo sich die Probleme von Binance Ledger unterschieden

Trotz einiger Ähnlichkeiten gab es für Binance Ledger bei unserer Online-Migrationsmission einige einzigartige Herausforderungen.

Erstens laufen die Backend-Systeme von Binance in einer verteilten Umgebung, während die Online-Datenbank DDL in einer monolithischen Umgebung läuft. Zweitens können wir es uns nicht leisten, alles auf einmal umzustellen, da die Daten das Eigentum unserer Benutzer waren. Und schließlich müssen wir sicherstellen, dass alle relevanten Dienste als Ganzes funktionieren, bevor wir mit der Massenmigration beginnen.

Wie im vorherigen Online-DDL-Beispiel bestand auch unsere Migration aus zwei Phasen:

  1. Die Synchronisierungsphase, in der ein spezieller Replikationsdienst erstellt wurde, um die Salden vom alten zum neuen Hauptbuch zu synchronisieren

  2. Die Umstellungsphase für jedes Konto

Phasenbasierte Ansätze

Die Aufgabe war groß, und wie man so schön sagt: Rom wurde auch nicht an einem Tag erbaut. Der Ansatz „Teile und herrsche“ funktioniert angesichts eines großen und komplexen Problembereichs oft wie am Schnürchen.

Phase 1: Replikation

Das Warum

Wir können unseren Denkprozess hier in zwei Hauptpunkten zusammenfassen:

  1. Wir haben Binance Ledger als neuen Slave modelliert, der sich dem bestehenden MySQL-Cluster anschließt, der das aktuelle Ledger-System betreibt. Durch den Einsatz von Replikationstechniken konnten wir die Guthaben der Benutzer asynchron vollständig synchron halten.

  2. Wir könnten dann den Produktionsverkehr wortwörtlich an Binance Ledger weiterleiten, um seine Richtigkeit und Robustheit zu validieren. Selbst wenn in dieser Phase etwas schief geht, hat dies keine Auswirkungen auf uns und unsere Benutzer.

Das was

Unten haben wir die gesamte Replikationspipeline dargestellt. Der kritische Pfad, auf den Sie achten sollten, ist:

Übertragen → Ledger → Binance Ledger Replikator → Binance Ledger

Das Wie

Wir haben den Replikationsprozess in zwei separate Schritte unterteilt:

  1. Habe einen Snapshot der Ledger-Datenbank erstellt und ihn dann in das Binance-Ledger importiert

  2. Das Binärprotokoll der Ledger-Datenbank wurde nach dem Zeitpunkt der Erstellung des Snapshots repliziert.

Schließlich würden die Daten der Salden und Saldenprotokolle zwischen dem alten Hauptbuch und dem Binance-Hauptbuch vollständig synchronisiert gehalten, was durch das vollständige Abstimmungsmodul weiter validiert werden kann.

Das Wann

Binance Ledger ging Anfang August 2022 live. Danach starteten wir den Replikationsprozess, der bis Mitte November 2022 dauerte. Dieser Prozess war für uns eine wichtige Phase, da die Korrektheit des neuen Ledger-Systems zu 100 % validiert werden musste. Dieser Schritt konnte nicht übersprungen werden, bevor mit der nächsten Migrationsphase fortgefahren wurde.

Letztendlich fanden wir keine Probleme und führten mehrere Release-Routinen durch, um uns mit der Situation vertraut zu machen. Der dreimonatige Prozess war nicht besonders schnell, aber für unser SAFU-Ziel war er notwendig.

Phase 2: Online-Migration

Das Warum

Um Hunderte Millionen Konten zu migrieren, haben wir einen individuellen Migrationsjob erstellt.

Das was

Nachfolgend haben wir den zentralen Migrationsablauf für ein Konto dargestellt:

Hier sind einige wichtige Hinweise, die Sie beachten sollten:

  1. Das Kontensystem verwaltet die Eigentumszuordnung für jedes Konto.

    1. Konto A → Hauptbuch

    2. Konto B → Binance Ledger

    3. Konto C → verboten

  1. Wenn vor der Migration eines Kontos eine gleichzeitige Transaktion aussteht, wird sie übersprungen, um die geschäftlichen Auswirkungen zu verringern.

  2. Wir haben die Eigentumszuordnung von „Ledger“ auf „Verboten“ geändert, wodurch weitere Aktualisierungen des Kontostands unterbunden und die Zuordnung somit unveränderlich gemacht wird.

  3. Wir haben die Salden zwischen dem alten Hauptbuch und dem Binance-Hauptbuch abgeglichen.

  4. Wir haben die Eigentumszuordnung von „verboten“ zu „Binance Ledger“ geändert, sodass zukünftige Kontostandsaktualisierungen direkt an das Binance Ledger weitergeleitet werden können.

Laut unserer Leistungsmetrik dauerte es von Schritt 3 bis Schritt 5 durchschnittlich 150 ms. Theoretisch können Benutzer während dieser 150 ms langen Migrationsperiode keine Transaktionen durchführen. Es stellte sich heraus, dass es keine betroffenen Transaktionen gab.

Die Hinrichtung

Bei Binance vertreten wir das Prinzip „Gute Ausführung statt sorgfältiger Planung“. Eine solide Ausführung ist entscheidend für unseren Erfolg und die Sicherheit unserer Gelder hat für uns immer oberste Priorität. Wir haben über einen Zeitraum von drei Wochen eine schrittweise Migrationsstrategie eingeführt, um Probleme so früh wie möglich zu erkennen und so das Ausmaß negativer Auswirkungen zu verringern.

Der Versöhnungsprozess

Der Abgleich ist enorm wichtig, um potenzielle Saldenanomalien rechtzeitig und unvoreingenommen zu erkennen. Wir können den Prozess nahezu in Echtzeit durchführen, um umgehend Maßnahmen zu ergreifen, bevor sich die Lage verschlechtert. Zwei Arten von Abgleichmodulen wurden speziell für den Online-Migrationsprozess entwickelt: Echtzeit und vollständig.

Echtzeit

Der auf Transaktionsebene basierende Abstimmungsprozess ist darauf ausgelegt, etwaige Fondsprobleme in Echtzeit zu erkennen.

Voll

Wir können regelmäßig einen vollständigen Abgleich auf der Grundlage der mit dem Data Warehouse synchronisierten Snapshots durchführen. Dieser Prozess stellt sicher, dass alle Salden zwischen dem alten Ledger und dem Binance Ledger identisch sind.

Nehmen wir beispielsweise an, dass 10 Millionen Benutzer noch immer das alte Ledger verwenden. Mithilfe dieser vollständigen Abstimmung können wir überprüfen, ob die Salden und Saldenprotokolle im alten Ledger und im Binance Ledger identisch sind.

Abschluss des Migrationsprozesses

Kurz gesagt wurde die Mission erreicht, indem 1) Replikationstechniken verwendet wurden, um die Richtigkeit des neuen Binance Ledger zu bestätigen, und 2) eine Migrationsstrategie für jedes Konto implementiert wurde, um die Engine langsam, sicher, aber zuverlässig zu aktualisieren.

Wir glauben, dass das oben genannte Online-Migrationsparadigma für ähnliche Aufgaben wiederverwendet werden kann. Wenn die besprochenen Prozesse und Themen Ihr Interesse geweckt haben, warum denken Sie nicht darüber nach, dem Team beizutreten? Wir sind immer auf der Suche nach engagierten Personen mit frischen Perspektiven auf unsere täglichen Herausforderungen bei Binance.

Verweise

  1. Wie Binance Ledger Ihr Binance-Erlebnis unterstützt

  2. GitHubs Online-Schemamigrationstool für MySQL

Weitere Informationen

  • Verwendung von MLOps zum Aufbau einer End-to-End-Pipeline für maschinelles Lernen in Echtzeit | Binance Blog

  • Ist Binance der richtige Ort für Sie? Gründe, Binance nicht beizutreten | Binance Blog