Hlavní Takeaways
Binance's Ledger ukládá zůstatky a transakce na účtech a zároveň umožňuje službám provádět transakce.
Vytváří podmínky potřebné pro vysokou propustnost, dostupnost 24/7 a přesnost dat na bitové úrovni.
Role Binance Ledger v zákulisí z ní dělá jednu z nejdůležitějších technologií Binance. Zde se dozvíte, jak přesně funguje a jaké problémy řeší při provozu největší světové kryptoburzy.
Přemýšleli jste někdy, co přesně vede Binance? S potřebou zpracovávat miliony transakcí denně napříč masivní uživatelskou základnou stojí za to podívat se na to, co má Binance pod pokličkou.
Základem technických operací Binance je její Ledger. Hlavní kniha ukládá zůstatky a transakce účtů a zároveň umožňuje službám provádět transakce.
Binance má vysoké požadavky na hlavní knihu
Jak si dokážete představit, požadavky na Ledger jsou vysoké, aby vyhovoval masivní poptávce uživatelů. Existují tři hlavní body, které je třeba vzít v úvahu:
Vysoká propustnost se schopností velkého množství TPS (transakcí za sekundu) ve špičce.
Dostupnost 24/7 bez prostojů.
Přesnost dat na bitové úrovni, bez ztráty finančních prostředků nebo transakčních chyb.
Podívejme se na příklad základního záznamu v hlavní knize. Zde je běžná transakce, při které účet 1 převede 1 BTC na účet 2.
Zůstatek před transakcí:
stůl 1
Zůstatek po transakci:
tabulka-2
V této transakci existují dva příkazy:
Účet 1 -1 BTC
Účet 2 + 1 BTC
Po provedení transakce budou uloženy dva protokoly zůstatků pro audit a odsouhlasení.
tabulka-3
Standardní průmyslové řešení
Jedno standardní průmyslové řešení Ledger je založeno na relační databázi. Vraťme se k předchozímu příkladu, dva příkazy transakce lze přeložit do dvou příkazů SQL a provést je v databázové transakci (tabulka-4).
tabulka-4
Výhody řešení
Je to docela jednoduché na implementaci.
Pro zlepšení výkonu je snadné použít běžné techniky ladění databáze, jako je rozdělení čtení/zápisu a sharding.
Pro vývojáře není těžké zotavit se z převzetí služeb při selhání a také monitorovat a udržovat komerční databázi.
Nevýhody řešení
TPS prudce klesne, když nastanou závodní podmínky kvůli uzamčení řad.
Je těžké horizontálně škálovat pro zlepšení výkonu.
Problém horkého účtu
Bohužel pro Binance, výše uvedené průmyslové řešení nesplňuje její vysoké požadavky. Když dojde k transakci, musí obsahovat zámky řádků každého zúčastněného řádku. Zatímco některé účty mají relativně málo transakcí k řešení, existují samozřejmě vytížené účty s mnoha souběžnými transakcemi. V tomto případě může pouze jedna transakce podržet zámek řádku účtu.
Ostatní transakce pak nemohou dělat nic jiného, než čekat na uvolnění zámku. Tuto situaci nazýváme horkým problémem s účtem a interní testy ukazují, že TPS v této situaci klesne nejméně 10krát. Tento problém můžete vidět v tabulce 5 níže.
Příklad horkého účtu:
tabulka-5
Řešení Binance's Ledger
Jak vyřešíme problém s horkým účtem?
Jedním z možných řešení našeho problému je inovativní převod vícevláknového modelu do jednovláknového režimu. Vyhnete se tak problému se závodními podmínkami a v důsledku toho nedojde k problému s horkým účtem.
Nový model závitu
Komunikace založená na zprávách
Po implementaci našeho nového modelu vláken je třeba vyřešit problém s komunikací. Vrstva stavového stroje je jednovláknová, ale síťová vrstva je vícevláknová, jak tedy mezi nimi efektivně komunikovat?
Disruptor [1] je dalším krokem v hádance. Vytváří vysoce výkonnou frontu bez uzamčení na základě návrhu kruhové vyrovnávací paměti.
Vysoká dostupnost
Doposud jsme dosahovali vysokého výkonu pomocí in-memory modelu a místního úložiště RocksDB [2]. Ale opět nastává nová výzva. Nyní se musíme postarat o vysokou dostupnost dat.
Pro zajištění konzistence dat mezi uzly používáme Raft Consensus Algorithm [3]. To znamená, že počet záloh dat se rovná počtu přítomných nevedoucích uzlů. Algoritmus také zajišťuje, že systém bude stále fungovat s alespoň polovinou uzlů v pořádku, což pomáhá poskytovat vysokou dostupnost služeb.
Role domén Raft:
Vůdce. Leader zpracovává všechny požadavky klientů a replikuje operaci všem následovníkům.
Následovník. Následovníci následují vůdce pro všechny operace. Pokud vůdce neuspěje, bude novým vůdcem zvolen jeden z následovníků.
Student. Studenti jsou nehlasující sledující, kteří odesílají každý záznam o změně idempotentu/transakce do jiných služeb.
Role domény Raft
CQRS (oddělení odpovědnosti za příkazový dotaz)
Dalším klíčovým kritériem, které chceme zajistit, je vyšší výkon zápisu do Ledgeru a schopnost pro rozmanitější podmínky dotazů. K tomu potřebujeme vytvořit různé domény. Doména raft poskytuje efektivnější zápis na základě rocksdb+raft a doména zobrazení naslouchá zprávám domény raft a ukládá je do relační databáze pro externí dotazy. Můžeme také implementovat segregaci odpovědnosti za dotazy na příkazy na architektonické úrovni.
Architektura knihy
Celková architektura
Podmínky mezi Raft a Ledger:
tabulka-6
Zobrazit role domény
Střed účetní knihy raftů
Konzumujte zprávu vytvořenou studentem a uložte data transakcí a zůstatků v MySQL pro účely dotazování.
Zpracování žádosti
Požadavek na transakci nejprve projde síťovou vrstvou, vrstvou hlavní knihy (obslužný program požadavku) a vrstvou raftu (synchronizace protokolu raftu). Poté se vrátí zpět do vrstvy účetní knihy (stavový stroj), síťové vrstvy (obslužný program odezvy) a nakonec vrátí odpověď klientovi.
Data jsou předávána přes frontu mezi dvěma vrstvami.
Síťová vrstva – Deserializuje požadavek RPC a umístí jej do fronty požadavků.
Ledger Layer – Získejte požadavek z fronty a připravte kontext. Poté zařadí metadata požadavku do fronty raftů.
Raft Layer – Získejte metadata požadavku z fronty raftů a synchronizujte je mezi všemi sledujícími. Poté zařadí výsledek do fronty aplikací.
Ledger Layer – Získejte data z aplikační fronty a aktualizujte stavový stroj. Poté zařadí výsledek do fronty odpovědí.
Síťová vrstva – Získejte výsledek z fronty odpovědí a vytvořte a serializujte data odpovědí, než je vrátíte klientovi.
Zpracování žádosti
Obnova dat
Každý uzel Ledger spustí obecný snímek na základě časového období. Kromě toho také implementujeme konzistentní snímek. Každý uzel se spouští se stejným indexem záznamu raftu, aby bylo zajištěno, že stavový stroj bude přesně stejný, když každý uzel spustí snímek. Snímek bude poté nahrán do S3 pro ověření pomocí Checker a jako studená záloha.
Když se Ledger restartuje, přečte místní snímek a znovu sestaví stavový stroj. Poté přehraje místní deník raftu a synchronizuje nejnovější deník od vedoucího, dokud nedosáhne nejnovějšího indexu. Pokud místní snímek nebo deník raftu neexistuje, bude získán od vedoucího.
Snímek a zotavení
Tolerance katastrof
Pro zlepšení dostupnosti a odolnosti proti chybám jsou uzly Ledger nasazeny v různých zónách. Dokud je více než polovina uzlů v pořádku, data se neztratí a převzetí služeb při selhání bude dokončeno během jedné sekundy.
I když selže celý cluster, což je velmi nízká pravděpodobnost, stále můžeme cluster obnovit prostřednictvím konzistentního snímku uloženého v Amazon S3 a získat nejnovější ztracená data prostřednictvím systému navazujícího na tok dat.
Odolnost proti chybám
Výkon
V následující tabulce jsou uvedeny hardwarové specifikace pro test výkonu
Interní testy dokazují, že 4-uzlový cluster (jeden vedoucí, dva následovníci a jeden žák) dokáže zpracovat více než 10 000 TPS. Podle návrhu cluster zpracovává všechny transakce jednu po druhé. Neexistuje vůbec žádný zámek a závodní stav. Takže ve scénáři horkého účtu je TPS stejně vysoká jako v normálních scénářích.
Hot účet TPS
Následující obrázek ukazuje latenci každé transakce. Většina transakcí mohla být dokončena do 10 ms. Pomalejší transakce mohly být dokončeny do 25 ms.
Latence ms
Napájení našich služeb pomocí Binance Ledger
Jak jste viděli, odpověď tradičního odvětví na problém horkých účtů neuspokojuje potřeby Binance a jejích zákazníků. Použitím přístupu navrženého speciálně pro infrastrukturu Binance jsme skončili s jednou z nejhladších dostupných zkušeností s výměnou a produktem. Jsme rádi, že se s vámi nyní můžeme podělit o naše zkušenosti a doufáme, že lépe pochopíte, co znamená, že služba jako Binance funguje.
Další informace o naší technologické infrastruktuře naleznete v následujícím článku:
(Binance Blog) Využití MLOps k vytvoření kompletního procesu strojového učení v reálném čase
(Binance Blog) Seznamte se s CTO: Rohit uvažuje o krypto, blockchainu, Web3 a jeho prvním měsíci na Binance
Reference
[1] Disruptor LMAX
[2] RocksDB
[3] Raft Consensus Algorithm
