ProHoster > Blogs > Administrācija > Maskavas biržas tirdzniecības un klīringa sistēmas arhitektūras evolūcija. 1. daļa

Maskavas biržas tirdzniecības un klīringa sistēmas arhitektūras evolūcija. 1. daļa

Maskavas biržas tirdzniecības un klīringa sistēmas arhitektūras evolūcija. 1. daļa

Sveiki visiem! Mani sauc Sergejs Kostanbajevs, Biržā es izstrādāju tirdzniecības sistēmas kodolu.

Kad Holivudas filmās rāda Ņujorkas biržu, tas vienmēr izskatās Ŕādi: cilvēku pūļi, visi kaut ko kliedz, vicina papÄ«rus, notiek pilnÄ«gs haoss. Pie mums Maskavas biržā tas nekad nav noticis, jo tirdzniecÄ«ba jau no paÅ”a sākuma ir notikusi elektroniski un balstās uz divām galvenajām platformām - Spectra (forex tirgus) un ASTS (ārvalstu birža, akciju un naudas tirgus). Un Å”odien es vēlos runāt par ASTS tirdzniecÄ«bas un klÄ«ringa sistēmas arhitektÅ«ras evolÅ«ciju, par dažādiem risinājumiem un atziņām. Stāsts bÅ«s garÅ”, tāpēc nācās to sadalÄ«t divās daļās.

Mēs esam viena no retajām biržām pasaulē, kas tirgo visu klaÅ”u aktÄ«vus un sniedz pilnu biržas pakalpojumu klāstu. Piemēram, pagājuÅ”ajā gadā ierindojāmies otrajā vietā pasaulē pēc obligāciju tirdzniecÄ«bas apjoma, 25. vietā starp visām biržām, 13. vietā kapitalizācijas ziņā starp publiskajām biržām.

Maskavas biržas tirdzniecības un klīringa sistēmas arhitektūras evolūcija. 1. daļa

Profesionāliem tirdzniecÄ«bas dalÄ«bniekiem kritiski svarÄ«gi ir tādi parametri kā reakcijas laiks, laika sadalÄ«juma stabilitāte (trÄ«ce) un visa kompleksa uzticamÄ«ba. PaÅ”laik mēs apstrādājam desmitiem miljonu darÄ«jumu dienā. Katra darÄ«juma apstrāde, ko veic sistēmas kodols, aizņem desmitiem mikrosekunžu. Protams, mobilo sakaru operatoriem Vecgada vakarā vai paÅ”iem meklētājiem ir lielāka slodze nekā pie mums, bet slodzes ziņā kopā ar iepriekÅ”minētajām Ä«paŔībām ar mums, man Ŕķiet, reti kurÅ” var salÄ«dzināt. Tajā paŔā laikā mums ir svarÄ«gi, lai sistēma ne mirkli nepalēninātu, darbotos absolÅ«ti stabili un visi lietotāji bÅ«tu vienlÄ«dzÄ«gi.

Nedaudz vēstures

1994. gadā Maskavas starpbanku valÅ«tas biržā (MICEX) tika palaista Austrālijas sistēma ASTS, un no Ŕī brīža var skaitÄ«t Krievijas elektroniskās tirdzniecÄ«bas vēsturi. 1998. gadā biržas arhitektÅ«ra tika modernizēta, lai ieviestu tirdzniecÄ«bu internetā. KopÅ” tā laika jaunu risinājumu un arhitektÅ«ras izmaiņu ievieÅ”anas ātrums visās sistēmās un apakÅ”sistēmās tikai uzņem apgriezienus.

Tajos gados apmaiņas sistēma strādāja ar augstākās klases aparatÅ«ru - Ä«paÅ”i uzticamiem HP Superdome 9000 serveriem (bÅ«vēti uz PA-RISC), kurā tika dublēts pilnÄ«gi viss: ievades/izvades apakÅ”sistēmas, tÄ«kls, operatÄ«vā atmiņa (patiesÄ«bā bija RAM masÄ«vs RAID), procesori (karstā maiņa). Bija iespējams mainÄ«t jebkuru servera komponentu, neapturot maŔīnu. Mēs paļāvāmies uz Ŕīm ierÄ«cēm un uzskatÄ«jām, ka tās ir praktiski droÅ”as. Operētājsistēma bija Unix lÄ«dzÄ«ga HP UX sistēma.

Taču aptuveni kopÅ” 2010. gada ir parādÄ«jusies parādÄ«ba, ko sauc par augstfrekvences tirdzniecÄ«bu (HFT) jeb augstfrekvences tirdzniecÄ«bu ā€“ vienkārÅ”i sakot, biržas roboti. Tikai 2,5 gadu laikā mÅ«su serveru slodze ir pieaugusi 140 reizes.

Maskavas biržas tirdzniecības un klīringa sistēmas arhitektūras evolūcija. 1. daļa

Tādu slodzi ar veco arhitektūru un aprīkojumu nebija iespējams izturēt. Vajadzēja kaut kā pielāgoties.

sākums

Pieprasījumus apmaiņas sistēmai var iedalīt divos veidos:

  • DarÄ«jumi. Ja vēlaties iegādāties dolārus, akcijas vai ko citu, nosÅ«tiet darÄ«jumu uz tirdzniecÄ«bas sistēmu un saņemat atbildi par panākumiem.
  • Informācijas pieprasÄ«jumi. Ja vēlaties uzzināt aktuālo cenu, apskatÄ«t pasÅ«tÄ«jumu grāmatu vai indeksus, pēc tam nosÅ«tÄ«t informācijas pieprasÄ«jumus.

Maskavas biržas tirdzniecības un klīringa sistēmas arhitektūras evolūcija. 1. daļa

Shematiski sistēmas kodolu var iedalīt trīs līmeņos:

  • Klientu lÄ«menis, kurā strādā brokeri un klienti. Viņi visi mijiedarbojas ar piekļuves serveriem.
  • Vārtejas serveri ir keÅ”atmiņas serveri, kas lokāli apstrādā visus informācijas pieprasÄ«jumus. Vai vēlaties uzzināt, par kādu cenu Å”obrÄ«d tiek tirgotas Sberbank akcijas? PieprasÄ«jums tiek nosÅ«tÄ«ts uz piekļuves serveri.
  • Bet, ja vēlaties iegādāties akcijas, tad pieprasÄ«jums nonāk centrālajā serverÄ« (Trade Engine). Katram tirgus veidam ir viens Ŕāds serveris, tiem ir bÅ«tiska loma, tieÅ”i viņiem mēs izveidojām Å”o sistēmu.

TirdzniecÄ«bas sistēmas kodols ir gudra atmiņas datu bāze, kurā visi darÄ«jumi ir maiņas darÄ«jumi. Bāze tika rakstÄ«ta C valodā, vienÄ«gās ārējās atkarÄ«bas bija libc bibliotēka un vispār nebija dinamiskas atmiņas pieŔķirÅ”anas. Lai samazinātu apstrādes laiku, sistēma sākas ar statisku masÄ«vu komplektu un statisku datu pārvietoÅ”anu: vispirms atmiņā tiek ielādēti visi paÅ”reizējās dienas dati un netiek veikta turpmāka piekļuve diskam, viss darbs tiek veikts tikai atmiņā. Kad sistēma startē, visi atsauces dati jau ir sakārtoti, tāpēc meklÄ“Å”ana darbojas ļoti efektÄ«vi un aizņem maz laika izpildlaikā. Visas tabulas ir veidotas ar uzmācÄ«giem sarakstiem un kokiem dinamiskām datu struktÅ«rām, lai tām nebÅ«tu nepiecieÅ”ama atmiņas pieŔķirÅ”ana izpildlaikā.

ÄŖsi apskatÄ«sim mÅ«su tirdzniecÄ«bas un klÄ«ringa sistēmas attÄ«stÄ«bas vēsturi.
Pirmā tirdzniecÄ«bas un klÄ«ringa sistēmas arhitektÅ«ras versija tika balstÄ«ta uz tā saukto Unix mijiedarbÄ«bu: tika izmantota koplietojamā atmiņa, semafori un rindas, un katrs process sastāvēja no viena pavediena. Å Ä« pieeja bija plaÅ”i izplatÄ«ta 1990. gadu sākumā.

Pirmajā sistēmas versijā bija divi Gateway lÄ«meņi un tirdzniecÄ«bas sistēmas centrālais serveris. Darba gaita bija Ŕāda:

  • Klients nosÅ«ta pieprasÄ«jumu, kas sasniedz Gateway. Tā pārbauda formāta derÄ«gumu (bet ne paÅ”us datus) un noraida nepareizas transakcijas.
  • Ja ir nosÅ«tÄ«ts informācijas pieprasÄ«jums, tas tiek izpildÄ«ts lokāli; ja mēs runājam par darÄ«jumu, tad tas tiek novirzÄ«ts uz centrālo serveri.
  • Pēc tam tirdzniecÄ«bas dzinējs apstrādā darÄ«jumu, pārveido vietējo atmiņu un nosÅ«ta atbildi uz darÄ«jumu un paÅ”u darÄ«jumu replikācijai, izmantojot atseviŔķu replikācijas dzinēju.
  • Vārteja saņem atbildi no centrālā mezgla un pārsÅ«ta to klientam.
  • Pēc kāda laika vārteja saņem transakciju, izmantojot replikācijas mehānismu, un Å”oreiz tā izpilda to lokāli, mainot datu struktÅ«ras, lai nākamie informācijas pieprasÄ«jumi parādÄ«tu jaunākos datus.

Faktiski tas apraksta replikācijas modeli, kurā vārteja pilnÄ«bā atkārtoja tirdzniecÄ«bas sistēmā veiktās darbÄ«bas. AtseviŔķs replikācijas kanāls nodroÅ”ināja, ka darÄ«jumi tika izpildÄ«ti vienā un tajā paŔā secÄ«bā vairākos piekļuves mezglos.

Tā kā kods bija ar vienu pavedienu, daudzu klientu apkalpoÅ”anai tika izmantota klasiska shēma ar procesa dakŔām. Tomēr visas datu bāzes dakÅ”a bija ļoti dārga, tāpēc tika izmantoti vieglie pakalpojumu procesi, kas savāca paketes no TCP sesijām un pārsÅ«tÄ«ja tās uz vienu rindu (SystemV Message Queue). Gateway un Trade Engine darbojās tikai ar Å”o rindu, veicot darÄ«jumus no turienes. Atbildi uz to nosÅ«tÄ«t vairs nebija iespējams, jo nebija skaidrs, kuram servisa procesam tā jāizlasa. Tāpēc mēs ķērāmies pie viltÄ«bas: katrs dakÅ”veida process izveidoja sev atbilžu rindu, un, kad pieprasÄ«jums nonāca ienākoÅ”ajā rindā, tai nekavējoties tika pievienots atbilžu rindas tags.

PastāvÄ«ga liela datu apjoma kopÄ“Å”ana no rindas uz rindu radÄ«ja problēmas, kas Ä«paÅ”i raksturÄ«gas informācijas pieprasÄ«jumiem. Tāpēc mēs izmantojām citu triku: papildus atbilžu rindai katrs process izveidoja arÄ« koplietojamo atmiņu (SystemV Shared Memory). Tajā tika ievietotas paÅ”as pakas, un rindā tika saglabāta tikai birka, kas ļāva atrast oriÄ£inālo iepakojumu. Tas palÄ«dzēja saglabāt datus procesora keÅ”atmiņā.

SystemV IPC ietver utilītas rindas stāvokļa, atmiņas un semaforu objektu apskatei. Mēs to aktīvi izmantojām, lai saprastu, kas konkrētajā brīdī notiek sistēmā, kur uzkrājās paketes, kas tika bloķēts utt.

Pirmās modernizācijas

Pirmkārt, mēs atbrÄ«vojāmies no viena procesa vārtejas. Tās bÅ«tisks trÅ«kums bija tas, ka tas varēja apstrādāt vai nu vienu replikācijas darÄ«jumu, vai vienu informācijas pieprasÄ«jumu no klienta. Un, palielinoties slodzei, Gateway prasÄ«s ilgāku laiku, lai apstrādātu pieprasÄ«jumus, un tas nevarēs apstrādāt replikācijas plÅ«smu. Turklāt, ja klients nosÅ«tÄ«ja darÄ«jumu, jums tikai jāpārbauda tā derÄ«gums un jāpārsÅ«ta tālāk. Tāpēc mēs aizstājām vienu vārtejas procesu ar vairākiem komponentiem, kas var darboties paralēli: vairāku pavedienu informācija un darÄ«jumu procesi, kas darbojas neatkarÄ«gi viens no otra koplietojamā atmiņas apgabalā, izmantojot RW bloÄ·Ä“Å”anu. Un tajā paŔā laikā mēs ieviesām nosÅ«tÄ«Å”anas un replikācijas procesus.

Augstas frekvences tirdzniecības ietekme

IepriekÅ” minētā arhitektÅ«ras versija pastāvēja lÄ«dz 2010. gadam. Tikmēr mēs vairs nebijām apmierināti ar HP Superdome serveru veiktspēju. Turklāt PA-RISC arhitektÅ«ra bija gandrÄ«z mirusi; pārdevējs nepiedāvāja nekādus nozÄ«mÄ«gus atjauninājumus. Tā rezultātā mēs sākām pāriet no HP UX/PA RISC uz Linux/x86. Pāreja sākās ar piekļuves serveru pielāgoÅ”anu.

Kāpēc mums atkal bija jāmaina arhitektūra? Fakts ir tāds, ka augstfrekvences tirdzniecība ir būtiski mainījusi sistēmas kodola slodzes profilu.

Teiksim, mums ir neliels darÄ«jums, kas izraisÄ«ja bÅ«tiskas cenas izmaiņas ā€“ kāds nopirka pusmiljardu dolāru. Pēc pāris milisekundēm visi tirgus dalÄ«bnieki to pamana un sāk veikt korekciju. Protams, pieprasÄ«jumi atrodas milzÄ«gā rindā, kuras notÄ«rÄ«Å”ana sistēmai prasÄ«s ilgu laiku.

Maskavas biržas tirdzniecības un klīringa sistēmas arhitektūras evolūcija. 1. daļa

Å ajā 50 ms intervālā vidējais ātrums ir aptuveni 16 tÅ«kstoÅ”i darÄ«jumu sekundē. Samazinot logu lÄ«dz 20 ms, mēs iegÅ«stam vidējo ātrumu 90 tÅ«kstoÅ”i transakciju sekundē, un maksimums ir 200 tÅ«kstoÅ”i darÄ«jumu. Citiem vārdiem sakot, slodze nav nemainÄ«ga, ar pēkŔņiem pārrāvumiem. Un pieprasÄ«jumu rinda vienmēr ir jāapstrādā ātri.

Bet kāpēc vispār ir rinda? Tātad mÅ«su piemērā daudzi lietotāji pamanÄ«ja cenu izmaiņas un attiecÄ«gi nosÅ«tÄ«ja darÄ«jumus. Tie nonāk Gateway, tas tos serializē, nosaka noteiktu secÄ«bu un nosÅ«ta tos tÄ«klam. MarÅ”rutētāji sajauc paketes un pārsÅ«ta tās tālāk. Kura paka ieradās pirmā, Å”is darÄ«jums ā€œuzvarējaā€. Tā rezultātā biržas klienti sāka pamanÄ«t, ka, ja viens un tas pats darÄ«jums tika nosÅ«tÄ«ts no vairākiem vārtiem, pieauga tā ātras apstrādes iespējas. DrÄ«z vien biržas roboti sāka bombardēt Gateway ar pieprasÄ«jumiem, un radās darÄ«jumu lavÄ«na.

Maskavas biržas tirdzniecības un klīringa sistēmas arhitektūras evolūcija. 1. daļa

Jauna evolūcijas kārta

Pēc plaÅ”as pārbaudes un izpētes mēs pārgājām uz reāllaika operētājsistēmas kodolu. Å im nolÅ«kam mēs izvēlējāmies RedHat Enterprise MRG Linux, kur MRG apzÄ«mē ziņojumapmaiņas reāllaika režģi. Reāllaika ielāpu priekÅ”rocÄ«ba ir tā, ka tie optimizē sistēmu pēc iespējas ātrākai izpildei: visi procesi ir sakārtoti FIFO rindā, kodolus var izolēt, nav izstumÅ”anas, visas transakcijas tiek apstrādātas stingrā secÄ«bā.

Maskavas biržas tirdzniecības un klīringa sistēmas arhitektūras evolūcija. 1. daļa
Sarkans - darbs ar rindu parastā kodolā, zaļŔ - darbs reāllaika kodolā.

Bet zema latentuma sasniegŔana parastajos serveros nav tik vienkārŔa:

  • SMI režīms, kas x86 arhitektÅ«rā ir pamats darbam ar svarÄ«gām perifērijas ierÄ«cēm, ievērojami traucē. Visu veidu aparatÅ«ras notikumu apstrādi un komponentu un ierīču pārvaldÄ«bu programmaparatÅ«ra veic tā sauktajā caurspÄ«dÄ«gajā SMI režīmā, kurā operētājsistēma vispār neredz, ko programmaparatÅ«ra dara. Parasti visi lielākie pārdevēji piedāvā Ä«paÅ”us programmaparatÅ«ras serveru paplaÅ”inājumus, kas ļauj samazināt SMI apstrādes apjomu.
  • Procesora frekvences dinamiskai kontrolei nevajadzētu bÅ«t, tas noved pie papildu dÄ«kstāves.
  • Kad failu sistēmas žurnāls tiek izskalots, kodolā notiek noteikti procesi, kas izraisa neparedzamu aizkavi.
  • Jums jāpievērÅ” uzmanÄ«ba tādām lietām kā CPU afinitāte, pārtraukumu radniecÄ«ba, NUMA.

Man jāsaka, ka tēma par Linux aparatÅ«ras un kodola iestatÄ«Å”anu reāllaika apstrādei ir pelnÄ«jusi atseviŔķu rakstu. Mēs pavadÄ«jām daudz laika eksperimentējot un pētot, pirms panācām labu rezultātu.

Pārejot no PA-RISC serveriem uz x86, praktiski nebija daudz jāmaina sistēmas kods, tikai pielāgojām un pārkonfigurējām. Tajā paŔā laikā mēs izlabojām vairākas kļūdas. Piemēram, sekas tam, ka PA RISC bija Big endian sistēma un x86 bija Little endian sistēma, ātri parādÄ«jās: piemēram, dati tika nolasÄ«ti nepareizi. Sarežģītāka kļūda bija PA RISC izmantotā kļūda konsekventi konsekventi (SecÄ«gi konsekventi) piekļuvi atmiņai, savukārt x86 var pārkārtot lasÄ«Å”anas darbÄ«bas, tāpēc kods, kas bija absolÅ«ti derÄ«gs vienā platformā, tika bojāts citā.

Pēc pārslēgÅ”anās uz x86 veiktspēja palielinājās gandrÄ«z trÄ«s reizes, vidējais darÄ«jumu apstrādes laiks samazinājās lÄ«dz 60 Ī¼s.

Tagad sīkāk apskatīsim, kādas galvenās izmaiņas ir veiktas sistēmas arhitektūrā.

Karsta rezerves epopeja

Pārejot uz preču serveriem, mēs apzinājāmies, ka tie ir mazāk uzticami. Tāpēc, veidojot jaunu arhitektÅ«ru, mēs a priori pieņēmām viena vai vairāku mezglu atteices iespēju. Tāpēc bija nepiecieÅ”ama karstā gaidstāves sistēma, kas varētu ļoti ātri pārslēgties uz rezerves maŔīnām.

Turklāt bija arī citas prasības:

  • Nekādā gadÄ«jumā nevajadzētu zaudēt apstrādātos darÄ«jumus.
  • Sistēmai ir jābÅ«t pilnÄ«gi pārredzamai mÅ«su infrastruktÅ«rai.
  • Klientiem nevajadzētu redzēt pārtrauktus savienojumus.
  • Rezervācijas nedrÄ«kst radÄ«t ievērojamu kavÄ“Å”anos, jo tas ir izŔķiroÅ”s faktors apmaiņai.

Veidojot karstā gaidstāves sistēmu, mēs neuzskatÄ«jām Ŕādus scenārijus kā dubultas kļūmes (piemēram, tÄ«kls vienā serverÄ« pārstāja darboties un galvenais serveris sastinga); neuzskatÄ«ja par kļūdu iespējamÄ«bu programmatÅ«rā, jo tās tiek identificētas testÄ“Å”anas laikā; un neuzskatÄ«ja par nepareizu aparatÅ«ras darbÄ«bu.

Rezultātā mēs nonācām pie Ŕādas shēmas:

Maskavas biržas tirdzniecības un klīringa sistēmas arhitektūras evolūcija. 1. daļa

  • Galvenais serveris tieÅ”i mijiedarbojās ar vārtejas serveriem.
  • Visas transakcijas, kas tika saņemtas galvenajā serverÄ«, tika uzreiz replicētas rezerves serverÄ«, izmantojot atseviŔķu kanālu. Å Ä·Ä«rējtiesnesis (gubernators) koordinēja maiņu, ja radās kādas problēmas.

    Maskavas biržas tirdzniecības un klīringa sistēmas arhitektūras evolūcija. 1. daļa

  • Galvenais serveris apstrādāja katru darÄ«jumu un gaidÄ«ja apstiprinājumu no rezerves servera. Lai samazinātu latentumu lÄ«dz minimumam, mēs izvairÄ«jāmies gaidÄ«t, kamēr darÄ«jums tiks pabeigts rezerves serverÄ«. Tā kā laiks, kas bija nepiecieÅ”ams, lai darÄ«jums pārvietotos pa tÄ«klu, bija salÄ«dzināms ar izpildes laiku, papildu latentums netika pievienots.
  • Mēs varējām pārbaudÄ«t tikai iepriekŔējā darÄ«juma galvenā un rezerves servera apstrādes statusu, un paÅ”reizējā darÄ«juma apstrādes statuss nebija zināms. Tā kā mēs joprojām izmantojām viena pavediena procesus, atbildes gaidÄ«Å”ana no Backup bÅ«tu palēninājusi visu apstrādes plÅ«smu, tāpēc mēs izdarÄ«jām saprātÄ«gu kompromisu: pārbaudÄ«jām iepriekŔējā darÄ«juma rezultātu.

Maskavas biržas tirdzniecības un klīringa sistēmas arhitektūras evolūcija. 1. daļa

Shēma darbojās Ŕādi.

Pieņemsim, ka galvenais serveris pārstāj reaģēt, bet vārtejas turpina sazināties. Rezerves serverÄ« notiek taimauts, tas sazinās ar pārvaldnieku, kurÅ” tam pieŔķir galvenā servera lomu, un visas vārtejas pārslēdzas uz jauno galveno serveri.

Ja galvenais serveris atgriežas tieÅ”saistē, tas arÄ« aktivizē iekŔējo taimautu, jo noteiktu laiku no vārtejas uz serveri nav saņemti zvani. Tad viņŔ arÄ« vērÅ”as pie gubernatora, un viņŔ viņu izslēdz no shēmas. Rezultātā birža strādā ar vienu serveri lÄ«dz tirdzniecÄ«bas perioda beigām. Tā kā servera atteices iespējamÄ«ba ir diezgan zema, Ŕī shēma tika uzskatÄ«ta par diezgan pieņemamu, tajā nebija sarežģītas loÄ£ikas un to bija viegli pārbaudÄ«t.

Turpināsim.

Avots: www.habr.com

Pievieno komentāru