Sziasztok! A nevem Sergey Kostanbaev, a tőzsdén a kereskedési rendszer magját fejlesztem.
Amikor a hollywoodi filmek bemutatják a New York-i tőzsdét, az mindig így néz ki: tömegek, mindenki kiabál valamit, hadonászik a papírokkal, teljes káosz van. Ez itt a moszkvai tőzsdén még nem fordult elő, mert a kereskedés kezdettől fogva elektronikusan zajlik, és két fő platformon alapul - Spectra (forex piac) és ASTS (deviza, részvény és pénzpiac). Ma pedig az ASTS kereskedési és elszámolási rendszer architektúrájának fejlődéséről, különféle megoldásokról és megállapításokról szeretnék beszélni. A történet hosszú lesz, így két részre kellett bontanom.
A világon azon kevés tőzsdék egyike vagyunk, amelyek minden osztályba tartozó eszközökkel kereskednek, és a tőzsdei szolgáltatások teljes skáláját nyújtják. Például tavaly a világon a második helyen álltunk a kötvénykereskedelem volumenében, a 25. helyen az összes tőzsde között, a 13. helyen kapitalizációban a nyilvános tőzsdék között.
A professzionális kereskedési résztvevők számára kritikusak az olyan paraméterek, mint a válaszidő, az időeloszlás stabilitása (jitter) és a teljes komplexum megbízhatósága. Jelenleg több tízmillió tranzakciót dolgozunk fel naponta. Az egyes tranzakciók feldolgozása a rendszermag által több tíz mikroszekundumot vesz igénybe. Természetesen a mobilszolgáltatók szilveszterkor vagy maguk a keresőmotorok nagyobb leterheltséggel bírnak, mint a miénk, de a leterheltség tekintetében, a fent említett jellemzőkkel párosulva, úgy tűnik, kevesen tudják összehasonlítani velünk. Ugyanakkor számunkra fontos, hogy a rendszer egy pillanatra se lassuljon, teljesen stabilan működjön, és minden felhasználó egyenrangú.
Egy kis történelem
1994-ben a moszkvai bankközi devizatőzsdén (MICEX) elindult az ausztrál ASTS rendszer, és ettől a pillanattól számítható az elektronikus kereskedés oroszországi története. 1998-ban modernizálták a tőzsdei architektúrát az internetes kereskedés bevezetése érdekében. Azóta minden rendszerben és alrendszerben csak lendületet vesz az új megoldások bevezetésének és az építészeti változtatások gyorsasága.
Azokban az években a csererendszer csúcsminőségű hardvereken működött – rendkívül megbízható HP Superdome 9000 szervereken (a), amelyben abszolút minden megkettőződött: bemeneti/kimeneti alrendszerek, hálózat, RAM (sőt, volt egy RAID tömb RAM), processzorok (hot-swappable). Bármely szerver komponenst le lehetett cserélni a gép leállítása nélkül. Bíztunk ezekben az eszközökben, és gyakorlatilag hibamentesnek tartottuk őket. Az operációs rendszer egy Unix-szerű HP UX rendszer volt.
Körülbelül 2010 óta azonban megjelent a nagyfrekvenciás kereskedés (HFT) vagy nagyfrekvenciás kereskedés – egyszerűen fogalmazva: tőzsdei robotok. Mindössze 2,5 év alatt 140-szeresére nőtt a szervereink terhelése.
Ekkora terhelést a régi építészettel és berendezésekkel lehetetlen volt elviselni. Valahogy alkalmazkodni kellett.
kezdet
A csererendszerhez intézett kérések két típusra oszthatók:
- Tranzakciók. Ha dollárt, részvényt vagy valami mást szeretne vásárolni, akkor elküldi a tranzakciót a kereskedési rendszernek, és választ kap a sikerről.
- Információkérések. Ha szeretné megtudni az aktuális árat, tekintse meg a rendelési könyvet vagy az indexeket, majd küldjön tájékoztatást.
Sematikusan a rendszer magja három szintre osztható:
- Az ügyfélszint, amelyen a brókerek és az ügyfelek dolgoznak. Mindegyik kölcsönhatásba lép a hozzáférési szerverekkel.
- Az átjárókiszolgálók gyorsítótárazó kiszolgálók, amelyek minden információkérést helyileg dolgoznak fel. Szeretné tudni, hogy jelenleg milyen áron kereskednek a Sberbank részvényei? A kérés eljut a hozzáférési szerverhez.
- De ha részvényeket szeretne vásárolni, akkor a kérés a központi szerverhez (Trade Engine) érkezik. Minden típusú piachoz tartozik egy ilyen szerver, ezek létfontosságú szerepet töltenek be, nekik hoztuk létre ezt a rendszert.
A kereskedési rendszer magja egy okos in-memory adatbázis, amelyben minden tranzakció tőzsdei tranzakció. Az alap C-ben íródott, az egyetlen külső függőség a libc könyvtár volt, és egyáltalán nem volt dinamikus memóriafoglalás. A feldolgozási idő csökkentése érdekében a rendszer egy statikus tömbkészlettel és statikus adatáthelyezéssel indul: először az aktuális nap összes adata betöltődik a memóriába, és nem történik további lemezelérés, minden munka csak a memóriában történik. A rendszer indulásakor az összes referenciaadat már rendezve van, így a keresés nagyon hatékonyan működik, és futásidőben kevés időt vesz igénybe. Minden tábla intruzív listákkal és fákkal készült a dinamikus adatstruktúrákhoz, így nem igényelnek memóriafoglalást futás közben.
Röviden tekintsük át kereskedési és elszámolási rendszerünk fejlődésének történetét.
A kereskedési és elszámolási rendszer architektúra első változata az úgynevezett Unix interakcióra épült: megosztott memóriát, szemaforokat és sorokat használtak, és minden folyamat egyetlen szálból állt. Ez a megközelítés az 1990-es évek elején terjedt el.
A rendszer első verziója a Gateway két szintjét és a kereskedési rendszer központi szerverét tartalmazta. A munkafolyamat a következő volt:
- Az ügyfél kérést küld, amely eljut az átjáróhoz. Ellenőrzi a formátum érvényességét (de magát az adatot nem), és elutasítja a hibás tranzakciókat.
- Ha információigénylést küldtek, azt helyben hajtják végre; ha tranzakcióról beszélünk, akkor az a központi szerverre kerül átirányításra.
- A kereskedési motor ezután feldolgozza a tranzakciót, módosítja a helyi memóriát, és választ küld a tranzakcióra és magának a tranzakciónak a replikációhoz egy külön replikációs motor segítségével.
- Az átjáró megkapja a választ a központi csomóponttól, és továbbítja azt az ügyfélnek.
- Egy idő után az átjáró megkapja a tranzakciót a replikációs mechanizmuson keresztül, és ezúttal helyileg hajtja végre, megváltoztatva az adatstruktúrát, hogy a következő információkérések a legfrissebb adatokat jelenítsék meg.
Valójában egy replikációs modellt ír le, amelyben az átjáró teljesen lemásolta a kereskedési rendszerben végrehajtott műveleteket. Egy külön replikációs csatorna biztosította, hogy a tranzakciók ugyanabban a sorrendben történjenek több hozzáférési csomóponton keresztül.
Mivel a kód egyszálú volt, sok ügyfél kiszolgálására egy klasszikus folyamatvillákkal ellátott sémát használtak. A teljes adatbázis elágazása azonban nagyon költséges volt, ezért olyan könnyű szolgáltatási folyamatokat használtak, amelyek a TCP-munkamenetekből gyűjtötték össze a csomagokat, és egy sorba (SystemV Message Queue) vitték át. A Gateway és a Trade Engine csak ezzel a sorral működött, és onnan vette át a tranzakciókat végrehajtásra. Már nem lehetett rá választ küldeni, mert nem volt egyértelmű, hogy melyik szervizfolyamatnak kell elolvasnia. Így hát egy trükkhöz folyamodtunk: minden elágazott folyamat egy válaszsort hozott létre magának, és amikor egy kérés érkezett a bejövő sorba, azonnal hozzáadták a válaszsor címkéjét.
A nagy mennyiségű adat folyamatos másolása sorról sorra problémákat okozott, különösen az információkéréseknél. Ezért egy másik trükköt alkalmaztunk: a válaszsoron kívül minden folyamat megosztott memóriát (SystemV Shared Memory) is hozott létre. Magukat a csomagokat helyezték el benne, és csak egy címkét tároltak a sorban, amely lehetővé tette az eredeti csomag megtalálását. Ez segített az adatok tárolásában a processzor gyorsítótárában.
A SystemV IPC segédprogramokat tartalmaz a várólista állapotának, a memória és a szemafor objektumok megtekintéséhez. Aktívan felhasználtuk ezt annak megértésére, hogy egy adott pillanatban mi történik a rendszerben, hol halmozódtak fel a csomagok, mi volt blokkolva stb.
Első frissítések
Először is megszabadultunk az egyfolyamatos átjárótól. Jelentős hátránya volt, hogy egy replikációs tranzakciót vagy egy ügyféltől érkező információkérést tudott kezelni. A terhelés növekedésével a Gateway tovább tart a kérések feldolgozásához, és nem tudja feldolgozni a replikációs folyamatot. Ezenkívül, ha az ügyfél küldött egy tranzakciót, akkor csak ellenőriznie kell az érvényességét, és továbbítania kell. Ezért az egyetlen átjáró folyamatot több, párhuzamosan futtatható összetevőre cseréltük: többszálú információs és tranzakciós folyamatok, amelyek egymástól függetlenül futnak egy megosztott memóriaterületen, RW zárolást használva. Ezzel egyidejűleg bevezettük a küldési és replikációs folyamatokat.
A nagyfrekvenciás kereskedés hatása
Az architektúra fenti változata 2010-ig létezett. Eközben már nem voltunk elégedettek a HP Superdome szerverek teljesítményével. Ezenkívül a PA-RISC architektúra gyakorlatilag halott volt, a gyártó nem kínált jelentős frissítéseket. Ennek eredményeként elkezdtünk áttérni a HP UX/PA RISC-ről a Linux/x86-ra. Az átállás a hozzáférési szerverek adaptálásával kezdődött.
Miért kellett újra az építészetet megváltoztatnunk? A tény az, hogy a nagyfrekvenciás kereskedés jelentősen megváltoztatta a rendszermag terhelési profilját.
Tegyük fel, hogy van egy kis tranzakciónk, ami jelentős árváltozást okozott – valaki félmilliárd dollárt vett. Néhány ezredmásodperc elteltével minden piaci szereplő észreveszi ezt, és elkezdi a korrekciót. Természetesen a kérelmek hatalmas sorban állnak, amelyeket a rendszernek hosszú ideig kell törölnie.
Ennél az 50 ms-os intervallumnál az átlagos sebesség körülbelül 16 ezer tranzakció másodpercenként. Ha az ablakot 20 ms-ra csökkentjük, 90 ezer tranzakciós átlagsebességet kapunk másodpercenként, 200 ezer tranzakcióval a csúcson. Más szóval, a terhelés nem állandó, hirtelen kitörésekkel. A kérések sorát pedig mindig gyorsan kell feldolgozni.
De miért van egyáltalán sor? Így példánkban sok felhasználó észlelte az árváltozást, és ennek megfelelően küldte el a tranzakciókat. Megérkeznek a Gateway-hez, az szerializálja őket, beállít egy bizonyos sorrendet, és elküldi a hálózatra. Az útválasztók megkeverik a csomagokat és továbbítják őket. Akinek először érkezett meg a csomag, az a tranzakció „nyert”. Ennek eredményeként a tőzsdei ügyfelek kezdték észrevenni, hogy ha ugyanazt a tranzakciót több átjáróról küldik, akkor megnőtt a gyors feldolgozásának esélye. Hamarosan a csererobotok kezdték bombázni a Gateway-t kérésekkel, és tranzakciók lavina tört ki.
Az evolúció új köre
Kiterjedt tesztelés és kutatás után áttértünk a valós idejű operációs rendszer kernelére. Ehhez a RedHat Enterprise MRG Linuxot választottuk, ahol az MRG a valós idejű üzenetküldő grid rövidítése. A valós idejű patchek előnye, hogy a lehető leggyorsabb végrehajtásra optimalizálják a rendszert: minden folyamat FIFO-sorba kerül, a magok elkülöníthetők, nincs kidobás, minden tranzakció szigorú sorrendben kerül feldolgozásra.
Piros - normál kernelben lévő sorral, zöld - valós idejű kernelben dolgozik.
De az alacsony késleltetés elérése normál szervereken nem olyan egyszerű:
- Az SMI mód, amely az x86 architektúrában a fontos perifériákkal való munka alapja, nagymértékben zavarja. Mindenféle hardveres esemény feldolgozását, valamint a komponensek és eszközök kezelését a firmware végzi az úgynevezett transzparens SMI módban, amelyben az operációs rendszer egyáltalán nem látja, mit csinál a firmware. Általános szabály, hogy minden nagyobb gyártó speciális bővítményeket kínál a firmware-szerverekhez, amelyek lehetővé teszik az SMI-feldolgozás mennyiségének csökkentését.
- A processzor frekvenciáját nem szabad dinamikusan szabályozni, ez további leálláshoz vezet.
- A fájlrendszer naplójának kiürítésekor bizonyos folyamatok történnek a kernelben, amelyek előre nem látható késést okoznak.
- Olyan dolgokra kell figyelnie, mint a CPU-affinitás, a megszakítási affinitás, a NUMA.
Azt kell mondanom, hogy a Linux hardver és kernel valós idejű feldolgozáshoz való beállításának témája külön cikket érdemel. Sok időt töltöttünk kísérletezéssel és kutatással, mielőtt jó eredményt értünk el.
A PA-RISC szerverekről x86-ra való átálláskor gyakorlatilag nem kellett sokat változtatnunk a rendszerkódon, csak adaptáltuk és újrakonfiguráltuk. Ezzel egy időben több hibát is kijavítottunk. Például annak a ténynek a következményei, hogy a PA RISC egy Big endian rendszer, az x86 pedig egy Little endian rendszer, gyorsan felszínre kerültek: például hibásan olvasták be az adatokat. A trükkösebb hiba az volt, amit a PA RISC használ () memória hozzáférést, míg az x86 átrendezheti az olvasási műveleteket, így az egyik platformon abszolút érvényes kód a másikon tönkrement.
Az x86-ra váltás után a teljesítmény közel háromszorosára nőtt, az átlagos tranzakciófeldolgozási idő 60 μs-ra csökkent.
Most nézzük meg közelebbről, hogy milyen kulcsfontosságú változtatásokat hajtottak végre a rendszer architektúrán.
Forró tartalék eposz
Amikor árukiszolgálókra váltottunk, tisztában voltunk azzal, hogy azok kevésbé megbízhatóak. Ezért egy új architektúra létrehozásakor eleve feltételeztük egy vagy több csomópont meghibásodásának lehetőségét. Ezért szükség volt egy forró készenléti rendszerre, amely nagyon gyorsan át tudott váltani tartalék gépekre.
Emellett további követelmények is voltak:
- Semmilyen körülmények között ne veszítse el a feldolgozott tranzakciókat.
- A rendszernek teljesen átláthatónak kell lennie az infrastruktúránk számára.
- Az ügyfelek nem láthatnak megszakadt kapcsolatokat.
- A foglalások nem okozhatnak jelentős késést, mert ez kritikus tényező a csere szempontjából.
A forró készenléti rendszer létrehozásakor az ilyen forgatókönyveket nem tekintettük kettős meghibásodásnak (például az egyik szerver hálózata leállt, és a fő szerver lefagyott); nem vette figyelembe a szoftverben előforduló hibák lehetőségét, mert azokat a tesztelés során azonosítják; és nem vette figyelembe a hardver hibás működését.
Ennek eredményeként a következő sémához jutottunk:
- A fő szerver közvetlenül kommunikált az átjárószerverekkel.
- A fő szerverre érkezett összes tranzakció egy külön csatornán keresztül azonnal replikálódott a tartalék szerverre. A választottbíró (kormányzó) koordinálta a váltást, ha bármilyen probléma merült fel.
- A fő szerver minden tranzakciót feldolgozott, és várt a biztonsági mentési szerver megerősítésére. A késleltetés minimálisra csökkentése érdekében elkerültük a tranzakció befejezését a biztonsági mentési szerveren. Mivel a tranzakció hálózaton való áthaladásához szükséges idő hasonló volt a végrehajtási időhöz, nem adtunk hozzá további késleltetést.
- Csak a fő és a tartalék szerver feldolgozási állapotát tudtuk ellenőrizni az előző tranzakcióhoz, és az aktuális tranzakció feldolgozási állapota ismeretlen volt. Mivel továbbra is egyszálú folyamatokat használtunk, a Backup válaszára várva a teljes feldolgozási folyamat lelassult volna, ezért ésszerű kompromisszumot kötöttünk: ellenőriztük az előző tranzakció eredményét.
A séma a következőképpen működött.
Tegyük fel, hogy a fő szerver nem válaszol, de az átjárók továbbra is kommunikálnak. Időtúllépés lép fel a tartalék szerveren, felveszi a kapcsolatot a kormányzóval, aki kijelöli a főszerver szerepét, és minden átjáró átvált az új főkiszolgálóra.
Ha a főszerver újra online állapotba kerül, az egy belső időtúllépést is kivált, mert egy bizonyos ideig nem érkezett hívás a szerver felé az átjáróról. Aztán a kormányzóhoz is fordul, aki kizárja őt a programból. Ennek eredményeként a tőzsde egy szerverrel működik a kereskedési időszak végéig. Mivel a szerver meghibásodásának valószínűsége meglehetősen kicsi, ezt a sémát meglehetősen elfogadhatónak tartották, nem tartalmazott bonyolult logikát és könnyen tesztelhető.
Продолжение следует.
Forrás: will.com