Hlavní Takeaways
Naše migrace Binance Ledger měla za cíl vyřešit problém s horkými účty, který je vlastní našemu bývalému relačnímu databázovému serveru.
Kryptoburza funguje 24 hodin denně, 7 dní v týdnu, 365 dní v roce, bez údržby, na rozdíl od běžné burzy, která má denní přestávky.
Migrace na nový Binance Ledger musela proběhnout online, udržovat aktiva uživatelů SAFU a neměla vůbec žádný obchodní dopad, takže zážitek pro koncové uživatele zůstal bezproblémový.
Zvolili jsme postupnou strategii migrace po jednotlivých účtech namísto přerušované strategie „vše najednou“, jak ji používá nástroj gh-ost.
Zjistěte více o naší migraci Binance Ledger a nástrojích a technikách používaných v průběhu celého procesu.
Binance Ledger je základem našich technických operací a zpracovává miliony každodenních transakcí v rámci rozsáhlé uživatelské základny. Více o systému, jeho cílech a výzvách se můžete dozvědět v našem blogu Jak Binance Ledger posiluje vaše Binance Experience. Náš proces migrace ze staré na novou verzi čelil typické výzvě: jak bychom mohli upgradovat motor za chodu, když je letadlo stále v letu? Museli jsme migrovat aktiva našich uživatelů a zachování fondů SAFU bylo naší nejvyšší prioritou.
Klíčové migrační výzvy Binance
Abychom dosáhli našich stanovených cílů, bylo třeba vyřešit následující seznam výzev:
Zajistěte úplnou správnost nové účetní knihy
Být schopen odhalit jakýkoli problém s fondy a opravit jej včas a přesně
Nedochází k prostojům pro upstreamy
Porovnání naší migrační mise s online databází DDL
Než se ponoříme do podrobností našeho řešení, podívejme se na běžný problém provádění online DDL (jazyk pro definici dat) pro velkou tabulku. Co je to vlastně DDL? Představte si tabulku se stovkami milionů řádků, kam potřebujeme přidat další sloupec. Chceme to udělat online, aniž by to narušilo podnikání.
K vyřešení tohoto problému se široce používá nástroj gh-ost a jak to funguje, můžete vidět na následujícím schématu.
Proces se v podstatě skládá ze dvou fází:
Fáze synchronizace, která pokračuje, dokud není nová tabulka plně identická s původní tabulkou. Existují dva druhy dat, která je třeba synchronizovat:
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 cutover výměna původní tabulky za novou bez přerušení probíhajících transakcí.
Kde se problémy Binance Ledger lišily
Navzdory některým podobnostem měla Binance Ledger v naší misi online migrace některé přirozeně jedinečné výzvy.
Za prvé, backendové systémy Binance fungují v distribuovaném prostředí, zatímco online databáze DDL je v monolitickém prostředí. Za druhé, nemůžeme si dovolit přijmout přístup úplného omezení, protože data byla majetkem našich uživatelů. A konečně musíme zajistit, aby všechny příslušné služby fungovaly jako celek, než zahájíme hromadnou migraci.
Stejně jako v předchozím příkladu online DDL i zde byly dvě fáze naší migrace:
Fáze synchronizace, kde byla speciálně vytvořena vyhrazená služba replikátoru pro synchronizaci zůstatků ze staré účetní knihy do nové účetní knihy
Fáze přerušování účtu po účtu
Fázové přístupy
Úkol to byl velký a jak se říká, Řím nebyl postaven za den. Přístup rozděl a panuj často funguje jako kouzlo tváří v tvář rozsáhlé a složité problematice.
Fáze 1: Replikace
Proč
Náš myšlenkový proces zde můžeme shrnout do dvou hlavních bodů:
Binance Ledger jsme modelovali jako nového slave připojení ke stávajícímu clusteru MySQL, který pohání současný systém účetní knihy. Využitím replikačních technik bychom mohli udržovat zůstatky uživatelů plně synchronizované asynchronně.
Poté bychom mohli směrovat produkční provoz doslovně do Binance Ledger, abychom ověřili jeho správnost a robustnost. I když se věci v této fázi zhorší, na nás a naše uživatele to nebude mít žádný dopad.
Co
Níže jsme ilustrovali celkový replikační kanál. Kritická cesta, které je třeba věnovat pozornost, je:
Přenos → Ledger → Replikátor Binance Ledger → Binance Ledger
Jak
Proces replikace jsme rozdělili do dvou samostatných kroků:
Vypsal snímek databáze hlavní knihy a poté jej importoval do hlavní knihy Binance
Replikoval protokol přihrádky databáze hlavní knihy po době, kdy byl snímek uložen.
Nakonec by data zůstatků a protokoly zůstatků byly udržovány v plné synchronizaci mezi starou účetní knihou a knihou Binance, což lze dále ověřit modulem úplného odsouhlasení.
Kdy
Binance Ledger byla spuštěna na začátku srpna 2022. Poté jsme zahájili proces replikace, který trval do poloviny listopadu 2022. Tento proces pro nás byl důležitým obdobím, protože správnost nového systému účetních knih musela být ověřena na 100 %. Tento krok nebylo možné přeskočit před pokračováním v další fázi migrace.
Nakonec jsme nenašli žádné problémy a provedli jsme několik rutin, abychom se se situací lépe seznámili. Tříměsíční proces nebyl nijak zvlášť rychlý, ale byl nezbytný pro náš cíl SAFU.
Fáze 2: online migrace
Proč
Pro migraci kolem stovek milionů účtů jsme vytvořili přizpůsobenou úlohu migrace.
Co
Níže uvádíme základní tok migrace pro jeden účet:
Zde je několik klíčových poznámek, které je třeba mít na paměti:
Systém účtů udržuje mapování vlastnictví pro každý účet.
Účet A → hlavní kniha
Účet B → Binance Ledger
Účet C → zakázán
Pokud by před migrací účtu existovala nějaká čekající souběžná transakce, byla by přeskočena, aby se snížil dopad na podnikání.
Změnili jsme mapování vlastnictví z hlavní knihy na zakázané, čímž jsme zakázali jakékoli další aktualizace zůstatku, takže je neměnné.
Srovnali jsme zůstatky mezi starou účetní knihou a účetní knihou Binance.
Změnili jsme mapování vlastnictví ze zakázaného na Binance Ledger, což umožňuje, aby budoucí aktualizace zůstatku byly směrovány přímo do Binance Ledger.
Podle naší metriky výkonu trvalo od kroku 3 do kroku 5 v průměru 150 ms. Teoreticky nemohou uživatelé během této 150 ms migrace provádět žádnou transakci. Ukázalo se, že transakce neměly žádný dopad.
Provedení
Ve společnosti Binance prosazujeme zásadu „dobré provedení před pečlivým plánováním“. Solidní provedení je pro náš úspěch životně důležité a bezpečnost fondů je vždy naší nejvyšší prioritou. Přijali jsme strategii postupné migrace po dobu tří týdnů, abychom problémy zachytili co nejdříve, což zase pomohlo snížit rozsah negativního dopadu.
Proces usmíření
Usmíření je nesmírně důležité při včasném odhalování potenciálních anomálií rovnováhy z nezaujatého pohledu. Můžeme provést proces téměř v reálném čase, abychom mohli rychle zasáhnout, než se věci zhorší. Speciálně pro proces online migrace jsou vyvinuty dva typy modulů pro odsouhlasení: v reálném čase a plné.
Reálný čas
Proces odsouhlasení na úrovni transakcí je vytvořen tak, aby detekoval jakýkoli problém s fondem v reálném čase.
Plný
Pravidelně můžeme provádět úplné odsouhlasení na základě snímků synchronizovaných s datovým skladem. Tento proces zajišťuje, že všechny zůstatky mezi starou knihou a knihou Binance jsou stejné.
Řekněme například, že ve staré účetní knize stále žije 10 milionů uživatelů. Toto úplné odsouhlasení můžeme použít k ověření, že zůstatky a protokoly zůstatků jsou stejné mezi starou knihou a knihou Binance.
Zabalit proces migrace
Stručně řečeno, mise byla splněna 1) použitím replikačních technik k ověření správnosti nového Binance Ledger 2) implementací strategie migrace po jednotlivých účtech s cílem upgradovat engine pomalu, bezpečně, ale jistě.
Věříme, že výše uvedené paradigma online migrace lze znovu použít v podobných úkolech. Pokud vás diskutované procesy a témata zaujaly, proč nezvážit připojení k týmu? Vždy hledáme oddané jednotlivce s novými pohledy na naše každodenní výzvy v Binance.
Reference
Jak Binance Ledger posiluje váš zážitek z Binance
Online nástroj pro migraci schémat GitHubu pro MySQL
Další čtení
Využití MLOps k vytvoření end-to-end kanálu strojového učení v reálném čase | Blog Binance
Je Binance to pravé místo pro vás? Důvody, proč se nepřipojit k Binance | Blog Binance