Překonávání unikátních výzev při migraci naší účetní knihy Binance
Hlavní body
Cílem migrace naší účetní knihy Binance bylo vyřešit problém horkých účtů, který se vyskytoval na našem bývalém serveru s relačními databázemi.
Kryptoměnová burza funguje 24 hodin denně, 7 dní v týdnů, 365 dní v roce, bez jakéhokoli okna na údržbu, čímž se liší od běžné burzy, která má každodenní přestávky.
Migrace na novou účetní knihu Binance musela být realizována online, se zachováním aktiv uživatelů SAFU a zamezením jakéhokoli dopadu na obchodování, aby zkušenost pro koncové uživatele nebyla nijak dotčena.
Zvolili jsme postupnou migrační strategii realizovanou po jednotlivých účtech, místo radikálního řezu, který řeší vše naráz, jako u nástroje ghost.
Zjistěte více o migraci naší účetní knihy Binance a o nástrojích a technikách používaných při tomto procesu.
Účetní kniha Binance podporuje náš technický provoz a každodenně zpracovává miliony transakcí napříč rozsáhlou uživatelskou základnou. Více informací o systému, jeho cílech a výzvách můžete zjistit na našem blogu Jak účetní kniha Binance vylepšuje vaši zkušenost s Binance. V rámci našeho procesu migrace ze staré na novou verzi jsme museli řešit obvyklý problém: jak vylepšit motor, když letadlo ještě pořád letí? Museli jsme přesunout aktiva našich uživatelů; naší hlavní prioritou přitom bylo udržet prostředky SAFU.
Nejdůležitější migrační výzvy Binance
Za účelem dosažení stanovených cílů musely být vyřešeny následující výzvy:
Zajistit úplnou správnost nové účetní knihy
Schopnost odhalit veškeré problémy s prostředky a rychle a přesně je vyřešit
Nezpůsobovat žádné prostoje u upstream procesů
Porovnání naší migrační mise s online databází DDL
Než se ponoříme do podrobností našeho řešení, pojďme se podívat na běžný problém aplikace online DDL (datový definiční jazyk) na rozsáhlou tabulku. Co přesně je DDL? Představte si tabulku se stovky milionů řádků, do které potřebujeme přidat další sloupec. Chceme to udělat online, aniž bychom jakkoli narušili obchodování.
K řešení tohoto problému se široce využívá nástroj ghost, jehož fungování vysvětluje následující schéma.
Celý proces se v podstatě skládá ze dvou fází:
Synchronizační fáze, ve které se pokračuje, dokud není nová tabulka zcela totožná s původní tabulkou. Přitom musíme synchronizovat dva druhy dat:
Stávající data
Přírůstková data (nová data vygenerovaná z původní tabulky během probíhajícího procesu migrace)
Fáze řezu či přepnutí, kdy se vyměňuje původní tabulka za novou, aniž by došlo k přerušení probíhajících transakcí.
V čem byly problémy účetní knihy Binance jiné
I přes některé podobnosti představovala naše online migrační mise účetní knihy Binance některé jedinečné výzvy.
Za prvé, backendové systémy Binance pracují v distribuovaném prostředí, zatímco online databáze DDL je jednolité prostředí. Za druhé, nemohli jsme si dovolit aplikovat jednorázový řez, protože data představovala aktiva našich uživatelů. A nakonec jsme potřebovali zajistit, aby všechny příslušné služby fungovaly jako celek, než přistoupíme k masové migraci.
Stejně jako u předešlého příkladu s DDL zahrnovala i naše migrace dvě fáze:
Fázi synchronizace, ve které jsme vytvořili specializovanou replikační službu, aby synchronizovala zůstatky ze staré účetní knihy do nové
Fáze řezu účet za účtem
Fázové přístupy
Úkol to byl velký a jak se říká, Řím nelze postavit za jeden den. V oblasti rozsáhlých a komplexních problémů často zázračně funguje přístup rozděl a panuj.
Fáze 1: Replikace
Proč
Svůj myšlenkový proces zde můžeme shrnout ve dvou hlavních bodech:
Účetní knihu Binance jsme vymodelovali jako nový slave či podřízený systém, který se připojil ke stávajícímu svazku MySQL, na kterém běží stávající systém účetní knihy. Pomocí replikačních technik jsme byli schopni asynchronně udržovat zůstatky uživatelů plně synchronizované.
Poté jsme mohli směrovat produkční provoz v přesné kopii na účetní knihu Binance, abychom si ověřili její správnost a odolnost. I pokud by se v této fázi něco nepodařilo, nemá to na nás ani naše uživatele žádný vliv.
Co
Níže jsme vykreslili celou replikační linku. Nejdůležitější trasa, které je třeba věnovat pozornost:
Převod → Účetní kniha → Replikátor účetní knihy Binance → Účetní kniha Binance
Jak
Replikační proces jsme rozdělili na dva samostatné kroky:
Zobrazili jsme snímek databáze účetní knihy a následně jej importovali do účetní knihy Binance
Replikovali jsme binární protokol databáze účetní knihy po zobrazení snímku.
Nakonec byla data zůstatků a protokolů zůstatků plně synchronizována mezi starou účetní knihou a účetní knihou Binance, což jsme si mohli dále ověřit modulem pro úplné srovnání.
Kdy
Účetní knihu Binance jsme spustili na začátku srpna 2022. Následně jsme zahájili proces replikace, který trval do poloviny listopadu 2022. Tento proces pro nás představoval důležité období, protože jsme museli ověřit 100% správnost systému nové účetní knihy. Tento krok jsme museli bezpodmínečně provést před další fází migrace.
V zásadě jsme nenarazili na žádné problémy a provedli jsme několik běžných postupů pro spuštění, abychom si byli situací jistější. Tento tříměsíční proces neproběhl příliš rychle, pro náš cíl SAFU byl však nezbytný.
Fáze 2: online migrace
Proč
Za účelem migrace stovek milionů účtů jsme sestavili specializovanou migrační jednotku.
Co
Níže popisujeme ústřední migrační tok u jednoho účtu:
Je přitom třeba mít na paměti následující hlavní faktory:
Účetní systém zachovává u každého účtu mapování vlastnictví.
Účet A → účetní kniha
Účet B → účetní kniha Binance
Účet C → zakázané
Před migrací účtu došlo v případě výskytu nevyřízené souběžné transakce k jejímu přeskočení, aby se omezil vliv na obchodování.
Mapování vlastnictví z účetní knihy jsme změnili na zakázané a znemožnili jsme veškeré další aktualizace zůstatku, takže se údaje staly neměnnými.
Sladili jsme zůstatky mezi starou účetní knihou a účetní knihou Binance.
Mapování vlastnictví jsme změnili ze zakázaného na účetní knihu Binance, čímž jsme umožnili budoucí aktualizace zůstatku směrovat přímo na účetní knihu Binance.
Podle naší výkonnostní metriky trvalo období mezi krokem 3 a krokem 5 v průměru 150 ms. Uživatelé teoreticky nemohli během tohoto migračního období 150 ms provádět žádné transakce. Ukázalo se, že to nemělo dopad na žádné transakce.
Provedení
V Binance se řídíme zásadou „správné provedení je důležitější než úzkostlivé plánování“. Solidní provedení je pro náš úspěch životně důležité a bezpečnost prostředků je vždy naší nejvyšší prioritou. Aplikovali jsme strategii postupné migrace během období tří týdnů, abychom zachytili problémy co možná nejdříve, a to pomohlo snížit rozsah negativních vlivů.
Proces sladění
Sladění je nesmírně důležité pro včasné a nezkreslené odhalení potenciálních anomálií zůstatků. Tento proces jsme schopni provádět takřka v reálném čase a přistoupit k rychlým opatřením, než dojde ke zhoršení situace. Speciálně pro proces online migrace byly vyvinuty dva typy vyrovnávacích modulů: v reálném čase a úplný.
V reálném čase
Proces vyrovnání na úrovni transakce je vystavěn tak, aby odhaloval veškeré problémy prostředků v reálném čase.
Úplný
Na základě snímků synchronizovaných s datovým skladem můžeme pravidelně provádět úplné slaďování. Tento proces zajišťuje, že jsou všechny zůstatky ve staré účetní knize i v účetní knize Binance shodné.
Řekněme, že máme ve staré účetní knize stále ještě uloženo 10 milionů uživatelů. Toto úplné vyrovnání můžeme použít k ověření toho, že zůstatky a protokoly zůstatků jsou ve staré účetní knize i v účetní knize Binance shodné.
Shrnutí celého procesu migrace
Ve zkratce lze říci, že misi jsme splnili díky 1) využití replikačních technik k ověření správnosti nové účetní knihy Binance a 2) migrační strategii realizované po jednotlivých účtech, která aktualizovala nástroj pomalu, bezpečně a s jistotou.
Věříme, že výše uvedené paradigma online migrace lze využít i u dalších podobných úkolů. Pokud vás popsané procesy a témata zaujaly, neměli byste zájem připojit se k našemu týmu? Vždy mezi sebou rádi uvítáme nadšené spolupracovníky, kteří budou ke každodenním výzvám u Binance přistupovat z nové perspektivy.