Þróun byggingarlistar viðskipta- og hreinsunarkerfis Moskvukauphallarinnar. 1. hluti

Hæ allir! Mitt nafn er Sergey Kostanbaev, í Kauphöllinni er ég að þróa kjarna viðskiptakerfisins.

Þegar Hollywood-myndir sýna kauphöllina í New York lítur það alltaf svona út: fjöldi fólks, allir hrópa eitthvað, veifa blöðum, algjör ringulreið er að gerast. Þetta hefur aldrei gerst hér í Kauphöllinni í Moskvu, því viðskipti hafa farið fram rafrænt frá upphafi og byggjast á tveimur megin kerfum - Spectra (gjaldeyrismarkaði) og ASTS (gjaldeyris-, hlutabréfa- og peningamarkaði). Og í dag vil ég tala um þróun arkitektúrs ASTS viðskipta- og jöfnunarkerfisins, um ýmsar lausnir og niðurstöður. Sagan verður löng, svo ég varð að skipta henni í tvo hluta.

Við erum ein af fáum kauphöllum í heiminum sem verslar með eignir af öllum flokkum og veitum alhliða skiptiþjónustu. Sem dæmi má nefna að á síðasta ári vorum við í öðru sæti í heiminum hvað varðar viðskiptamagn með skuldabréf, 25. sæti yfir allar kauphallir, 13. sæti í hástöfum meðal opinberra kauphalla.

Fyrir faglega viðskiptaaðila eru slíkar breytur eins og viðbragðstími, stöðugleiki tímadreifingar (jitter) og áreiðanleiki alls fléttunnar mikilvægar. Við vinnum nú úr tugum milljóna viðskipta á dag. Vinnsla kerfiskjarnans á hverri færslu tekur tugi míkrósekúndna. Auðvitað eru farsímafyrirtæki á gamlárskvöld eða leitarvélar sjálfar með meira vinnuálag en okkar, en hvað vinnuálag varðar, samfara ofangreindum eiginleikum, geta fáir borið sig saman við okkur, sýnist mér. Á sama tíma er mikilvægt fyrir okkur að kerfið hægi ekki á sér í eina sekúndu, virki algerlega stöðugt og allir notendur standi jafnfætis.

Smá saga

Árið 1994 var ástralska ASTS kerfið sett á markað í Moskvu millibankagjaldeyriskauphöllinni (MICEX) og frá því augnabliki er hægt að telja rússneska sögu rafrænna viðskipta. Árið 1998 var kauphallararkitektúr nútímavæða til að kynna netviðskipti. Síðan þá hefur hraði nýrra lausna og byggingarbreytinga í öllum kerfum og undirkerfum aðeins farið vaxandi.

Á þessum árum vann skiptikerfið á háþróuðum vélbúnaði - ofuráreiðanlegum HP Superdome 9000 netþjónum (byggt á PA-RISC), þar sem algerlega allt var afritað: inntaks/úttaks undirkerfi, netkerfi, vinnsluminni (reyndar var RAID fylki af vinnsluminni), örgjörvar (hægt að skipta um). Það var hægt að breyta hvaða miðlara íhlut sem er án þess að stöðva vélina. Við treystum á þessi tæki og töldum þau nánast bilunarörugg. Stýrikerfið var Unix-líkt HP UX kerfi.

En síðan um 2010 hefur komið fram fyrirbæri sem kallast hátíðniviðskipti (HFT), eða hátíðniviðskipti - einfaldlega sagt, kauphallarvélmenni. Á aðeins 2,5 árum hefur álagið á netþjóna okkar aukist 140 sinnum.

Það var ómögulegt að standast slíkt álag með gamla byggingarlist og búnaði. Það þurfti einhvern veginn að aðlagast.

Byrja

Beiðnum til skiptikerfisins má skipta í tvennt:

• Viðskipti. Ef þú vilt kaupa dollara, hlutabréf eða eitthvað annað sendir þú viðskipti í viðskiptakerfið og færð svar um árangur.
• Upplýsingabeiðnir. Ef þú vilt komast að núverandi verð skaltu skoða pöntunarbókina eða vísitölur og senda síðan upplýsingabeiðnir.

Á skýringarmynd má skipta kjarna kerfisins í þrjú stig:

• Viðskiptavinastigið, þar sem miðlarar og viðskiptavinir starfa. Þeir hafa allir samskipti við aðgangsþjóna.
• Gáttarþjónar eru skyndiminniþjónar sem vinna úr öllum upplýsingabeiðnum á staðnum. Viltu vita á hvaða verði hlutabréf Sberbank eru í viðskiptum? Beiðnin fer á aðgangsþjóninn.
• En ef þú vilt kaupa hlutabréf, þá fer beiðnin til miðlara (Trade Engine). Það er einn slíkur netþjónn fyrir hverja tegund af markaði, þeir gegna mikilvægu hlutverki, það er fyrir þá sem við bjuggum til þetta kerfi.

Kjarni viðskiptakerfisins er snjall gagnagrunnur í minni þar sem öll viðskipti eru skiptiviðskipti. Grunnurinn var skrifaður í C, einu ytri ósjálfstæðin voru libc bókasafnið og það var engin kraftmikil minnisúthlutun. Til að stytta vinnslutímann byrjar kerfið með kyrrstæðu setti fylki og með kyrrstæðum gagnaflutningi: Í fyrsta lagi eru öll gögn fyrir núverandi dag hlaðin inn í minnið og ekki er frekari aðgangur að disknum framkvæmdur, öll vinna fer aðeins fram í minni. Þegar kerfið fer í gang eru öll viðmiðunargögn þegar flokkuð, þannig að leitin virkar mjög vel og tekur lítinn tíma í keyrslu. Allar töflur eru gerðar með uppáþrengjandi listum og trjám fyrir kraftmikla gagnabyggingu þannig að þær krefjast ekki minnisúthlutunar á keyrslutíma.

Við skulum fara stuttlega yfir sögu þróunar viðskipta- og jöfnunarkerfisins okkar.
Fyrsta útgáfan af viðskipta- og hreinsunarkerfisarkitektúrnum var byggð á svokölluðu Unix samspili: notað var sameiginlegt minni, semafórur og biðraðir og hvert ferli samanstóð af einum þræði. Þessi aðferð var útbreidd snemma á tíunda áratugnum.

Fyrsta útgáfan af kerfinu innihélt tvö stig af Gateway og miðlægum miðlara viðskiptakerfisins. Vinnuflæðið var svona:

• Viðskiptavinurinn sendir beiðni sem nær til hliðsins. Það athugar réttmæti sniðsins (en ekki gögnin sjálf) og hafnar röngum viðskiptum.
• Ef upplýsingabeiðni hefur verið send er hún framkvæmd á staðnum; ef við erum að tala um viðskipti, þá er þeim vísað á miðlæga netþjóninn.
• Viðskiptavélin vinnur síðan viðskiptin, breytir staðbundnu minni og sendir svar við viðskiptunum og viðskiptunum sjálfum til afritunar með því að nota sérstaka afritunarvél.
• Gáttin tekur við svarinu frá miðlægum hnút og sendir það áfram til viðskiptavinarins.
• Eftir nokkurn tíma tekur gáttin á móti viðskiptunum í gegnum afritunarkerfið og í þetta skiptið framkvæmir það á staðnum og breytir gagnaskipulagi þess þannig að næstu upplýsingabeiðnir birti nýjustu gögnin.

Reyndar lýsir það afritunarlíkani þar sem Gateway endurtekur algjörlega aðgerðirnar sem gerðar voru í viðskiptakerfinu. Sérstök afritunarrás tryggði að færslur voru framkvæmdar í sömu röð yfir marga aðgangshnúta.

Þar sem kóðinn var einn-þráður var klassískt kerfi með vinnslugöfflum notað til að þjóna mörgum viðskiptavinum. Hins vegar var mjög dýrt að punga allan gagnagrunninn, þannig að léttir þjónustuferli voru notaðir sem söfnuðu pökkum úr TCP lotum og færðu þá í eina biðröð (SystemV Message Queue). Gateway og Trade Engine virkuðu aðeins með þessari biðröð og tóku viðskipti þaðan til framkvæmdar. Ekki var lengur hægt að senda svar við því þar sem ekki var ljóst hvaða þjónustuferli ætti að lesa það. Þannig að við gripum til bragðarefur: hvert gaffalað ferli skapaði svarröð fyrir sig og þegar beiðni kom inn í móttekna biðröð var merki fyrir svarröðina strax bætt við hana.

Stöðugt að afrita mikið magn af gögnum úr biðröð í biðröð skapaði vandamál, sérstaklega dæmigert fyrir upplýsingabeiðnir. Þess vegna notuðum við annað bragð: til viðbótar við svarröðina bjó hvert ferli einnig til sameiginlegt minni (SystemV Shared Memory). Pakkarnir sjálfir voru settir í það og aðeins merki var geymt í biðröðinni, sem gerir manni kleift að finna upprunalega pakkann. Þetta hjálpaði til við að geyma gögn í skyndiminni örgjörva.

SystemV IPC inniheldur tól til að skoða stöðu biðraðar, minnis og semafórhluta. Við notuðum þetta virkan til að skilja hvað var að gerast í kerfinu á tilteknu augnabliki, hvar pakkar söfnuðust upp, hvað var lokað o.s.frv.

Fyrstu nútímavæðingar

Fyrst af öllu, losuðum við okkur við einsferlis Gateway. Verulegur galli þess var að hann gat annað hvort séð um eina afritunarfærslu eða eina upplýsingabeiðni frá viðskiptavini. Og eftir því sem álagið eykst mun Gateway taka lengri tíma að vinna úr beiðnum og mun ekki geta unnið úr afritunarflæðinu. Að auki, ef viðskiptavinurinn sendi færslu, þá þarftu aðeins að athuga réttmæti þess og senda það áfram. Þess vegna skiptum við einu Gateway ferlinu út fyrir marga íhluti sem geta keyrt samhliða: margþráða upplýsingar og viðskiptaferli sem keyra óháð hvert öðru á sameiginlegu minni svæði með því að nota RW læsingu. Og á sama tíma kynntum við sendingar- og afritunarferli.

Áhrif hátíðniviðskipta

Ofangreind útgáfa af arkitektúrnum var til 2010. Á meðan vorum við ekki lengur ánægð með frammistöðu HP Superdome netþjóna. Að auki var PA-RISC arkitektúrinn nánast dauður; söluaðilinn bauð ekki upp á neinar marktækar uppfærslur. Í kjölfarið fórum við að færa okkur frá HP UX/PA RISC yfir í Linux/x86. Umskiptin hófust með aðlögun aðgangsþjóna.

Af hverju þurftum við að breyta arkitektúrnum aftur? Staðreyndin er sú að hátíðniviðskipti hafa verulega breytt álagssniðinu á kerfiskjarnanum.

Segjum að við séum með lítil viðskipti sem olli verulegri verðbreytingu - einhver keypti hálfan milljarð dollara. Eftir nokkrar millisekúndur taka allir markaðsaðilar eftir þessu og byrja að leiðrétta. Auðvitað raðast beiðnir í risastóra biðröð sem kerfið mun taka langan tíma að hreinsa.

Á þessu 50 ms bili er meðalhraði um 16 þúsund færslur á sekúndu. Ef við lækkum gluggann í 20 ms fáum við meðalhraða upp á 90 þúsund færslur á sekúndu, með 200 þúsund færslur í hámarki. Með öðrum orðum, álagið er ekki stöðugt, með skyndilegum springum. Og biðröð beiðna verður alltaf að vinna hratt.

En hvers vegna er biðröð yfirleitt? Svo, í okkar dæmi, tóku margir notendur eftir verðbreytingunni og sendu viðskipti í samræmi við það. Þeir koma til Gateway, það serializes þá, setur ákveðna röð og sendir þá á netið. Beinar stokka pakkana og senda þá áfram. Sá pakki sem kom fyrst, þessi viðskipti „vann“. Fyrir vikið tóku kauphallarviðskiptavinir að taka eftir því að ef sama viðskiptin voru send frá nokkrum hliðum, þá jukust líkurnar á hraðri vinnslu þeirra. Fljótlega fóru skiptivélmenni að sprengja Gateway með beiðnum og snjóflóð viðskipta kom upp.

Ný þróunarlota

Eftir miklar prófanir og rannsóknir skiptum við yfir í rauntíma stýrikerfiskjarna. Fyrir þetta völdum við RedHat Enterprise MRG Linux, þar sem MRG stendur fyrir skilaboð í rauntíma. Kosturinn við rauntíma plástra er að þeir hagræða kerfið fyrir hraðasta mögulega framkvæmd: öll ferli eru raðað upp í FIFO biðröð, kjarna er hægt að einangra, engar útkastanir, öll viðskipti eru unnin í ströngri röð.

Rauður - vinna með biðröð í venjulegum kjarna, grænn - vinna í rauntíma kjarna.

En það er ekki svo auðvelt að ná lágri leynd á venjulegum netþjónum:

• SMI stillingin, sem í x86 arkitektúrnum er grunnurinn að því að vinna með mikilvæg jaðartæki, truflar mikið. Vinnsla á alls kyns vélbúnaðaratburðum og stjórnun á íhlutum og tækjum fer fram með fastbúnaðinum í svokölluðum gagnsæjum SMI ham, þar sem stýrikerfið sér alls ekki hvað vélbúnaðinn er að gera. Að jafnaði bjóða allir helstu söluaðilar sérstakar viðbætur fyrir fastbúnaðarþjóna sem gera kleift að draga úr magni SMI vinnslu.
• Það ætti ekki að vera kraftmikil stjórn á tíðni örgjörva, þetta leiðir til viðbótar niður í miðbæ.
• Þegar skráarkerfisskráin er skoluð, eiga sér stað ákveðin ferli í kjarnanum sem valda ófyrirsjáanlegum töfum.
• Þú þarft að borga eftirtekt til hlutum eins og CPU sækni, trufla sækni, NUMA.

Ég verð að segja að efnið um að setja upp Linux vélbúnað og kjarna fyrir rauntímavinnslu á skilið sérstaka grein. Við eyddum miklum tíma í tilraunir og rannsóknir áður en við náðum góðum árangri.

Þegar við fluttum frá PA-RISC netþjónum yfir í x86 þurftum við nánast ekki að breyta kerfiskóðanum mikið, við bara aðlaguðum hann og endurstillum hann. Á sama tíma laguðum við nokkrar villur. Til dæmis komu afleiðingarnar af því að PA RISC var Big endian kerfi og x86 var Little endian kerfi fljótt upp á yfirborðið: til dæmis voru gögn lesin rangt. The trickier galla var að PA RISC notar stöðugt í samræmi (Samræmt í röð) minnisaðgang, en x86 getur endurraðað lestraraðgerðum, þannig að kóði sem var algerlega gildur á einum vettvangi brotnaði á öðrum.

Eftir að skipt var yfir í x86 jókst árangur næstum þrefalt, meðalvinnslutími viðskipta minnkaði í 60 μs.

Við skulum nú skoða nánar hvaða helstu breytingar hafa verið gerðar á kerfisarkitektúrnum.

Heitur varasjóður

Þegar skipt var yfir í vöruþjóna vorum við meðvituð um að þeir voru ekki eins áreiðanlegir. Þess vegna, þegar við bjuggum til nýjan arkitektúr, gerðum við fyrirfram ráð fyrir möguleikanum á bilun á einum eða fleiri hnútum. Því vantaði heitt biðkerfi sem gæti mjög fljótt skipt yfir í varavélar.

Að auki voru aðrar kröfur:

• Undir engum kringumstæðum ættir þú að tapa unnum færslum.
• Kerfið verður að vera algjörlega gagnsætt fyrir innviðum okkar.
• Viðskiptavinir ættu ekki að sjá fallnar tengingar.
• Fyrirvarar ættu ekki að leiða til verulegrar töfar því þetta er mikilvægur þáttur fyrir skiptin.

Þegar búið var að búa til heitt biðkerfi, litum við ekki á slíkar aðstæður sem tvöfaldar bilanir (til dæmis hætti netkerfið á einum netþjóni að virka og aðalþjónninn fraus); taldi ekki möguleika á villum í hugbúnaðinum vegna þess að þær eru auðkenndar við prófun; og taldi ekki rangan rekstur vélbúnaðarins.

Í kjölfarið komumst við að eftirfarandi kerfi:

• Aðalþjónninn hafði bein samskipti við Gateway netþjónana.
• Allar færslur sem berast á aðalþjóninum voru samstundis afritaðar á varaþjóninn í gegnum sérstaka rás. Dómarinn (seðlabankastjóri) samræmdi skiptin ef einhver vandamál komu upp.

  

• Aðalþjónninn afgreiddi hverja færslu og beið eftir staðfestingu frá varaþjóninum. Til að halda leynd í lágmarki forðuðumst við að bíða eftir að viðskiptunum yrði lokið á afritunarþjóninum. Þar sem tíminn sem það tók fyrir viðskipti að ferðast um netið var sambærilegur við framkvæmdartímann var engum viðbótartöfum bætt við.
• Við gátum aðeins athugað vinnslustöðu aðal- og varaþjóna fyrir fyrri færslu og vinnslustaða núverandi færslu var óþekkt. Þar sem við vorum enn að nota einn-þráða ferla, að bíða eftir svari frá Backup hefði hægt á öllu vinnsluflæðinu, þannig að við gerðum sanngjarna málamiðlun: við athuguðum niðurstöðu fyrri viðskipta.

Áætlunin virkaði sem hér segir.

Segjum að aðalþjónninn hætti að svara, en hliðin halda áfram að hafa samskipti. Tímaleysi kemur á varaþjóninum, hann hefur samband við seðlabankastjóra, sem úthlutar honum hlutverki aðalþjónsins, og allar hliðar skipta yfir í nýja aðalþjóninn.

Ef aðalþjónninn kemur aftur á netið kveikir það einnig á innri tímamörkum, því engin símtöl hafa verið til netþjónsins frá Gateway í ákveðinn tíma. Þá snýr hann sér líka til seðlabankastjóra og útilokar hann frá áætluninni. Fyrir vikið vinnur kauphöllin með einum netþjóni til loka viðskiptatímabilsins. Þar sem líkurnar á bilun á netþjóni eru frekar litlar var þetta kerfi talið alveg ásættanlegt, það innihélt ekki flókna rökfræði og var auðvelt að prófa.

Til að halda áfram.

Heimild: www.habr.com