Die evolusie van die argitektuur van die handels- en skoonmaakstelsel van die Moskou-beurs. Deel 1

Hi almal! My naam is Sergey Kostanbaev, by die Exchange ontwikkel ek die kern van die handelstelsel.

Wanneer Hollywood-rolprente die New Yorkse aandelebeurs wys, lyk dit altyd so: menigte mense, almal skree iets, swaai papiere, volledige chaos is aan die gebeur. Dit het nog nooit hier op die Moskou-beurs gebeur nie, want handel is van die begin af elektronies gedoen en is gebaseer op twee hoofplatforms - Spectra (forex mark) en ASTS (buitelandse valuta, aandele en geldmark). En vandag wil ek praat oor die evolusie van die argitektuur van die ASTS-handels- en skoonmaakstelsel, oor verskeie oplossings en bevindings. Die storie sal lank wees, so ek moes dit in twee dele opdeel.

Ons is een van die min beurse in die wêreld wat bates van alle klasse verhandel en 'n volledige reeks ruildienste verskaf. Byvoorbeeld, verlede jaar was ons tweede in die wêreld in terme van effekteverhandelingsvolume, 25ste plek onder alle aandelebeurse, 13de plek in kapitalisasie onder openbare beurse.

Vir professionele handelsdeelnemers is sulke parameters soos reaksietyd, stabiliteit van tydverspreiding (jitter) en betroubaarheid van die hele kompleks van kritieke belang. Ons verwerk tans tienmiljoene transaksies per dag. Die verwerking van elke transaksie deur die stelselkern neem tientalle mikrosekondes. Selfoonoperateurs op Oujaarsaand of soekenjins self het natuurlik 'n hoër werklading as ons s'n, maar wat werklading betref, tesame met bogenoemde kenmerke, kan min met ons vergelyk, lyk dit my. Terselfdertyd is dit vir ons belangrik dat die stelsel nie vir 'n sekonde vertraag nie, absoluut stabiel werk en alle gebruikers op gelyke voet is.

'n Bietjie geskiedenis

In 1994 is die Australiese ASTS-stelsel op die Moskou Interbank-valutabeurs (MICEX) bekendgestel, en vanaf daardie oomblik kan die Russiese geskiedenis van elektroniese handel getel word. In 1998 is die beursargitektuur gemoderniseer om internethandel bekend te stel. Sedertdien het die spoed van implementering van nuwe oplossings en argitektoniese veranderinge in alle stelsels en substelsels net momentum gekry.

In daardie jare het die uitruilstelsel op hoë-end hardeware gewerk - ultrabetroubare HP Superdome 9000-bedieners (gebou op die PA-RISIKO), waarin absoluut alles gedupliseer is: invoer-/afvoersubstelsels, netwerk, RAM (in werklikheid was daar 'n RAID-skikking van RAM), verwerkers (hot-swappable). Dit was moontlik om enige bedienerkomponent te verander sonder om die masjien te stop. Ons het op hierdie toestelle staatgemaak en as feitlik faalveilig beskou. Die bedryfstelsel was 'n Unix-agtige HP UX-stelsel.

Maar sedert ongeveer 2010 het 'n verskynsel ontstaan ​​genaamd hoëfrekwensiehandel (HFT), of hoëfrekwensiehandel - eenvoudig gestel, aandelebeursrobotte. In net 2,5 jaar het die las op ons bedieners 140 keer toegeneem.

Dit was onmoontlik om so 'n las met die ou argitektuur en toerusting te weerstaan. Dit was nodig om op een of ander manier aan te pas.

Begin

Versoeke aan die uitruilstelsel kan in twee tipes verdeel word:

• Transaksies. As jy dollars, aandele of iets anders wil koop, stuur jy 'n transaksie na die handelstelsel en ontvang 'n antwoord oor sukses.
• Inligting versoeke. As jy die huidige prys wil uitvind, sien die bestelboek of indekse en stuur dan inligtingsversoeke.

Skematies kan die kern van die stelsel in drie vlakke verdeel word:

• Die kliëntvlak, waarop makelaars en kliënte werk. Hulle het almal interaksie met toegangsbedieners.
• Gateway-bedieners is kasbedieners wat alle inligtingversoeke plaaslik verwerk. Wil jy weet teen watter prys Sberbank-aandele tans verhandel? Die versoek gaan na die toegangsbediener.
• Maar as jy aandele wil koop, gaan die versoek na die sentrale bediener (Trade Engine). Daar is een so 'n bediener vir elke tipe mark, hulle speel 'n belangrike rol, dit is vir hulle dat ons hierdie stelsel geskep het.

Die kern van die handelstelsel is 'n slim in-geheue databasis waarin alle transaksies ruiltransaksies is. Die basis is in C geskryf, die enigste eksterne afhanklikhede was die libc-biblioteek en daar was glad geen dinamiese geheuetoewysing nie. Om verwerkingstyd te verminder, begin die stelsel met 'n statiese stel skikkings en met statiese dataverskuiwing: eerstens word alle data vir die huidige dag in die geheue gelaai, en geen verdere skyftoegang word uitgevoer nie, alle werk word slegs in die geheue uitgevoer. Wanneer die stelsel begin, is alle verwysingsdata reeds gesorteer, so die soektog werk baie doeltreffend en neem min tyd in looptyd. Alle tabelle is gemaak met indringende lyste en bome vir dinamiese datastrukture sodat hulle nie geheuetoewysing tydens looptyd benodig nie.

Kom ons gaan kortliks oor die geskiedenis van die ontwikkeling van ons handels- en skoonmaakstelsel.
Die eerste weergawe van die handels- en skoonmaakstelselargitektuur is gebou op die sogenaamde Unix-interaksie: gedeelde geheue, semafore en toue is gebruik, en elke proses het uit 'n enkele draad bestaan. Hierdie benadering was wydverspreid in die vroeë 1990's.

Die eerste weergawe van die stelsel het twee vlakke van Gateway en 'n sentrale bediener van die handelstelsel bevat. Die werkvloei was soos volg:

• Die kliënt stuur 'n versoek wat die Gateway bereik. Dit kontroleer die geldigheid van die formaat (maar nie die data self nie) en verwerp verkeerde transaksies.
• Indien 'n inligtingsversoek gestuur is, word dit plaaslik uitgevoer; as ons van 'n transaksie praat, word dit na die sentrale bediener herlei.
• Die handelsenjin verwerk dan die transaksie, wysig plaaslike geheue en stuur 'n reaksie op die transaksie en die transaksie self vir replikasie deur 'n aparte replikasie-enjin te gebruik.
• Die Gateway ontvang die antwoord vanaf die sentrale nodus en stuur dit aan die kliënt.
• Na 'n geruime tyd ontvang die Gateway die transaksie deur die replikasiemeganisme, en hierdie keer voer dit dit plaaslik uit, en verander sy datastrukture sodat die volgende inligtingsversoeke die nuutste data vertoon.

Trouens, dit beskryf 'n replikasiemodel waarin die Gateway die aksies wat in die handelstelsel uitgevoer is, heeltemal herhaal het. 'n Aparte replikasiekanaal het verseker dat transaksies in dieselfde volgorde oor verskeie toegangsnodusse uitgevoer is.

Aangesien die kode enkeldraad was, is 'n klassieke skema met prosesvurke gebruik om baie kliënte te bedien. Dit was egter baie duur om die hele databasis te vurk, so liggewig diensprosesse is gebruik wat pakkies van TCP-sessies versamel en na een tou oorgedra het (SystemV Message Queue). Gateway en Trade Engine het slegs met hierdie tou gewerk en transaksies van daar af geneem vir uitvoering. Dit was nie meer moontlik om 'n reaksie daarop te stuur nie, want dit was nie duidelik watter diensproses dit moet lees nie. Ons het dus 'n truuk gebruik: elke gevurkte proses het vir homself 'n antwoordwag geskep, en wanneer 'n versoek in die inkomende tou gekom het, is 'n merker vir die antwoordry onmiddellik daarby gevoeg.

Die voortdurende kopiëring van groot hoeveelhede data van tou na tou het probleme geskep, veral tipies vir inligtingsversoeke. Daarom het ons nog 'n truuk gebruik: bykomend tot die reaksie-tou het elke proses ook gedeelde geheue geskep (SystemV Shared Memory). Die pakkette self is daarin geplaas, en slegs 'n etiket is in die tou gestoor, sodat 'n mens die oorspronklike pakket kon vind. Dit het gehelp om data in die verwerkerkas te stoor.

SystemV IPC bevat nutsprogramme om die toestand van tou-, geheue- en semafoorvoorwerpe te bekyk. Ons het dit aktief gebruik om te verstaan ​​wat op 'n spesifieke oomblik in die stelsel gebeur, waar pakkies opgehoop het, wat geblokkeer is, ens.

Eerste moderniserings

Eerstens het ons ontslae geraak van die enkel-proses Gateway. Die beduidende nadeel daarvan was dat dit óf een replikasietransaksie óf een inligtingversoek van 'n kliënt kon hanteer. En soos die vrag toeneem, sal Gateway langer neem om versoeke te verwerk en sal dit nie die replikasievloei kan verwerk nie. Daarbenewens, as die kliënt 'n transaksie gestuur het, hoef u net die geldigheid daarvan na te gaan en dit verder aan te stuur. Daarom het ons die enkele Gateway-proses vervang met veelvuldige komponente wat parallel kan loop: multi-threaded inligting en transaksieprosesse wat onafhanklik van mekaar loop op 'n gedeelde geheue area met behulp van RW locking. En terselfdertyd het ons versending- en replikasieprosesse ingestel.

Impak van hoëfrekwensiehandel

Bogenoemde weergawe van die argitektuur het tot 2010 bestaan. Intussen was ons nie meer tevrede met die werkverrigting van HP Superdome-bedieners nie. Daarbenewens was die PA-RISC-argitektuur feitlik dood; die verkoper het geen noemenswaardige opdaterings aangebied nie. As gevolg hiervan het ons van HP UX/PA RISC na Linux/x86 begin beweeg. Die oorgang het begin met die aanpassing van toegangsbedieners.

Hoekom moes ons weer die argitektuur verander? Die feit is dat hoëfrekwensiehandel die lasprofiel op die stelselkern aansienlik verander het.

Kom ons sê ons het 'n klein transaksie wat 'n aansienlike prysverandering veroorsaak het - iemand het 'n halfmiljard dollar gekoop. Na 'n paar millisekondes merk alle markdeelnemers dit op en begin om 'n regstelling te maak. Natuurlik staan ​​versoeke in 'n groot tou, wat die stelsel lank sal neem om skoon te maak.

Met hierdie 50 ms-interval is die gemiddelde spoed ongeveer 16 duisend transaksies per sekonde. As ons die venster na 20 ms verminder, kry ons 'n gemiddelde spoed van 90 duisend transaksies per sekonde, met 200 duisend transaksies op die hoogtepunt. Met ander woorde, die las is nie konstant nie, met skielike sarsies. En die tou versoeke moet altyd vinnig verwerk word.

Maar hoekom is daar hoegenaamd 'n tou? Dus, in ons voorbeeld, het baie gebruikers die prysverandering opgemerk en transaksies dienooreenkomstig gestuur. Hulle kom na Gateway, dit serialiseer hulle, stel 'n sekere volgorde en stuur hulle na die netwerk. Roeteerders skommel die pakkies en stuur dit aan. Wie se pakkie eerste aangekom het, daardie transaksie “gewen”. Gevolglik het uitruilkliënte begin agterkom dat as dieselfde transaksie vanaf verskeie Gateways gestuur is, die kanse op vinnige verwerking daarvan toegeneem het. Kort voor lank het ruilrobotte Gateway met versoeke begin bombardeer, en 'n stortvloed van transaksies het ontstaan.

'n Nuwe rondte van evolusie

Na uitgebreide toetsing en navorsing het ons oorgeskakel na die kern van die intydse bedryfstelsel. Hiervoor het ons RedHat Enterprise MRG Linux gekies, waar MRG staan ​​vir boodskappe-intydse rooster. Die voordeel van intydse pleisters is dat dit die stelsel optimaliseer vir die vinnigste moontlike uitvoering: alle prosesse word in 'n EIEU-tou geplaas, kerne kan geïsoleer word, geen uitwerpings nie, alle transaksies word in streng volgorde verwerk.

Rooi - werk met 'n tou in 'n gewone kern, groen - werk in 'n intydse kern.

Maar om lae latency op gereelde bedieners te bereik is nie so maklik nie:

• Die SMI-modus, wat in die x86-argitektuur die basis is om met belangrike randapparatuur te werk, meng grootliks in. Verwerking van alle soorte hardeware-gebeurtenisse en bestuur van komponente en toestelle word deur die firmware in die sogenaamde deursigtige SMI-modus uitgevoer, waarin die bedryfstelsel glad nie sien wat die firmware doen nie. As 'n reël bied alle groot verskaffers spesiale uitbreidings vir firmware-bedieners wat dit moontlik maak om die hoeveelheid SMI-verwerking te verminder.
• Daar behoort geen dinamiese beheer van die verwerkerfrekwensie te wees nie, dit lei tot bykomende stilstand.
• Wanneer die lêerstelsellogboek gespoel word, vind sekere prosesse in die kern plaas wat onvoorspelbare vertragings veroorsaak.
• Jy moet aandag gee aan dinge soos CPU-affiniteit, Interrupt-affiniteit, NUMA.

Ek moet sê dat die onderwerp van die opstel van Linux hardeware en kern vir intydse verwerking 'n aparte artikel verdien. Ons het baie tyd spandeer om te eksperimenteer en navorsing te doen voordat ons 'n goeie resultaat behaal het.

Toe ons van PA-RISC-bedieners na x86 geskuif het, hoef ons feitlik nie die stelselkode veel te verander nie, ons het dit net aangepas en herkonfigureer. Terselfdertyd het ons verskeie foute reggemaak. Byvoorbeeld, die gevolge van die feit dat PA RISC 'n Big endian-stelsel was, en x86 'n Little endian-stelsel, het vinnig opgeduik: data is byvoorbeeld verkeerd gelees. Die moeiliker fout was wat PA RISC gebruik konsekwent konsekwent (Opeenvolgend konsekwent) geheue toegang, terwyl x86 leesbewerkings kan herrangskik, sodat kode wat absoluut geldig was op een platform op 'n ander gebreek het.

Nadat na x86 oorgeskakel is, het werkverrigting byna drievoudig toegeneem, die gemiddelde transaksieverwerkingstyd het tot 60 μs afgeneem.

Kom ons kyk nou van nader na watter sleutelveranderinge aan die stelselargitektuur aangebring is.

Warm reserwe-epos

Toe ons na kommoditeitsbedieners oorgeskakel het, was ons bewus daarvan dat hulle minder betroubaar was. Daarom, toe ons 'n nuwe argitektuur skep, het ons a priori die moontlikheid van mislukking van een of meer nodusse aanvaar. Daarom was 'n warm bystandstelsel nodig wat baie vinnig na rugsteunmasjiene kon oorskakel.

Daarbenewens was daar ander vereistes:

• Jy moet onder geen omstandighede verwerkte transaksies verloor nie.
• Die stelsel moet absoluut deursigtig wees vir ons infrastruktuur.
• Kliënte moet nie konneksies sien wat gedaal is nie.
• Besprekings moet nie noemenswaardige vertraging veroorsaak nie, want dit is 'n kritieke faktor vir die uitruil.

Toe ons 'n warm bystandstelsel geskep het, het ons nie sulke scenario's as dubbele mislukkings oorweeg nie (byvoorbeeld, die netwerk op een bediener het opgehou werk en die hoofbediener het gevries); nie die moontlikheid van foute in die sagteware oorweeg nie omdat dit tydens toetsing geïdentifiseer word; en het nie die verkeerde werking van die hardeware in ag geneem nie.

As gevolg hiervan het ons by die volgende skema gekom:

• Die hoofbediener het direk met die Gateway-bedieners interaksie gehad.
• Alle transaksies wat op die hoofbediener ontvang is, is onmiddellik via 'n aparte kanaal na die rugsteunbediener gerepliseer. Die arbiter (Goewerneur) het die oorskakeling gekoördineer indien enige probleme opduik.

  

• Die hoofbediener het elke transaksie verwerk en gewag vir bevestiging van die rugsteunbediener. Om vertraging tot 'n minimum te beperk, het ons vermy om te wag vir die transaksie om op die rugsteunbediener te voltooi. Aangesien die tyd wat dit geneem het vir 'n transaksie om oor die netwerk te reis vergelykbaar was met die uitvoeringstyd, is geen bykomende vertraging bygevoeg nie.
• Ons kon slegs die verwerkingstatus van die hoof- en rugsteunbedieners vir die vorige transaksie nagaan, en die verwerkingstatus van die huidige transaksie was onbekend. Aangesien ons steeds enkeldraadprosesse gebruik het, sou die wag vir 'n antwoord van Backup die hele verwerkingsvloei vertraag het, so ons het 'n redelike kompromie aangegaan: ons het die resultaat van die vorige transaksie nagegaan.

Die skema het soos volg gewerk.

Kom ons sê die hoofbediener hou op om te reageer, maar die Gateways gaan voort om te kommunikeer. 'n Time-out vind plaas op die rugsteunbediener, dit kontak die Goewerneur, wat dit die rol van die hoofbediener toeken, en alle Gateways skakel oor na die nuwe hoofbediener.

As die hoofbediener weer aanlyn kom, veroorsaak dit ook 'n interne uitteltyd, want daar was vir 'n sekere tyd geen oproepe na die bediener vanaf die Gateway nie. Dan wend hy hom ook tot die Goewerneur, en hy sluit hom uit van die skema. As gevolg hiervan werk die uitruil met een bediener tot die einde van die handelsperiode. Aangesien die waarskynlikheid van 'n bedienermislukking redelik laag is, is hierdie skema as redelik aanvaarbaar beskou; dit het nie komplekse logika bevat nie en was maklik om te toets.

Om voortgesit te word.

Bron: will.com