La evoluo de la arkitekturo de la komerca kaj klarigsistemo de la Moskva Interŝanĝo. Parto 1

Saluton al ĉiuj! Mia nomo estas Sergey Kostanbaev, ĉe la Interŝanĝo mi disvolvas la kernon de la komerca sistemo.

Kiam Hollywood-filmoj montras la Novjorkan Borson, ĝi ĉiam aspektas jene: amasoj da homoj, ĉiuj ion krias, svingas paperojn, okazas kompleta kaoso. Ĉi tio neniam okazis ĉi tie en la Moskva Interŝanĝo, ĉar komerco estis kondukita elektronike de la komenco kaj baziĝas sur du ĉefaj platformoj - Spectra (forex-merkato) kaj ASTS (valut-valuto, akcio kaj monmerkato). Kaj hodiaŭ mi volas paroli pri la evoluo de la arkitekturo de la sistemo de komerco kaj purigado de ASTS, pri diversaj solvoj kaj trovoj. La rakonto estos longa, do mi devis dividi ĝin en du partojn.

Ni estas unu el la malmultaj interŝanĝoj en la mondo, kiu komercas aktivaĵojn de ĉiuj klasoj kaj provizas plenan gamon da interŝanĝaj servoj. Ekzemple, pasintjare ni okupis la duan lokon en la mondo laŭ kvanto de obligacio-komerco, 25-a loko inter ĉiuj borsoj, 13-a loko en kapitaligo inter publikaj interŝanĝoj.

Por profesiaj komercaj partoprenantoj, tiaj parametroj kiel responda tempo, stabileco de tempodistribuo (jitter) kaj fidindeco de la tuta komplekso estas kritikaj. Ni nuntempe prilaboras dekojn da milionoj da transakcioj tage. La pretigo de ĉiu transakcio per la sistema kerno daŭras dekojn da mikrosekundoj. Kompreneble, telefonistoj en la silvestro aŭ serĉiloj mem havas pli altan laborŝarĝon ol la nia, sed laŭ laborŝarĝo, kunigita al la supre menciitaj trajtoj, malmultaj povas kompari kun ni, ŝajnas al mi. Samtempe, gravas por ni, ke la sistemo ne malrapidiĝas dum unu sekundo, funkcias absolute stabile kaj ĉiuj uzantoj estas sur egala bazo.

Iom da historio

En 1994, la aŭstralia ASTS-sistemo estis lanĉita ĉe la Moskva Interbanka Valuto-Interŝanĝo (MICEX), kaj de tiu momento oni povas kalkuli la rusan historion de elektronika komerco. En 1998, la interŝanĝo-arkitekturo estis modernigita por enkonduki Interretan komercon. Ekde tiam, la rapideco de efektivigo de novaj solvoj kaj arkitekturaj ŝanĝoj en ĉiuj sistemoj kaj subsistemoj nur akiras impeton.

En tiuj jaroj, la interŝanĝsistemo funkciis sur altkvalita aparataro - ultra-fidindaj HP Superdome 9000-serviloj (konstruitaj sur la PA-RISC), en kiu absolute ĉio estis duobligita: subsistemoj de enigo/eligo, reto, RAM (fakte, estis RAID-tabelo de RAM), procesoroj (varme interŝanĝeblaj). Eblis ŝanĝi ajnan servilan komponanton sen haltigi la maŝinon. Ni fidis ĉi tiujn aparatojn kaj konsideris ilin preskaŭ sekuraj. La operaciumo estis Unikso-simila HP UX-sistemo.

Sed ekde proksimume 2010, aperis fenomeno nomata altfrekvenca komerco (HFT), aŭ altfrekvenca komerco - simple dirite, borsaj robotoj. En nur 2,5 jaroj, la ŝarĝo sur niaj serviloj pliiĝis 140 fojojn.

Estis neeble elteni tian ŝarĝon kun la malnova arkitekturo kaj ekipaĵo. Necesis iel adaptiĝi.

Начало

Petoj al la interŝanĝsistemo povas esti dividitaj en du tipojn:

• Transakcioj. Se vi volas aĉeti dolarojn, akciojn aŭ ion alian, vi sendas transakcion al la komerca sistemo kaj ricevas respondon pri sukceso.
• Informpetoj. Se vi volas ekscii la nunan prezon, vidu la mendlibron aŭ indeksojn, tiam sendu informpetojn.

Skeme, la kerno de la sistemo povas esti dividita en tri nivelojn:

• La klientnivelo, ĉe kiu makleristoj kaj klientoj laboras. Ili ĉiuj interagas kun alirserviloj.
• Gateway-serviloj estas kaŝmemoraj serviloj, kiuj loke prilaboras ĉiujn informpetojn. Ĉu vi volas scii, je kia prezo komercas akcioj de Sberbank? La peto iras al la alirservilo.
• Sed se vi volas aĉeti akciojn, tiam la peto iras al la centra servilo (Trade Engine). Estas unu tia servilo por ĉiu tipo de merkato, ili ludas esencan rolon, estas por ili, ke ni kreis ĉi tiun sistemon.

La kerno de la komerca sistemo estas lerta en-memora datumbazo, en kiu ĉiuj transakcioj estas interŝanĝaj transakcioj. La bazo estis skribita en C, la nuraj eksteraj dependecoj estis la libc-biblioteko kaj tute ne estis dinamika memor-atribuo. Por redukti la tempon de prilaborado, la sistemo komenciĝas per senmova aro de tabeloj kaj kun statika datuma translokado: unue, ĉiuj datumoj de la nuna tago estas ŝarĝitaj en memoron, kaj neniu plua disko aliro estas plenumita, ĉiu laboro estas efektivigita nur en memoro. Kiam la sistemo komenciĝas, ĉiuj referencaj datumoj jam estas ordigitaj, do la serĉo funkcias tre efike kaj daŭras malmulte da tempo en rultempo. Ĉiuj tabeloj estas faritaj kun trudemaj listoj kaj arboj por dinamikaj datumstrukturoj tiel ke ili ne postulas memorasignon ĉe rultempo.

Ni mallonge trarigardu la historion de la evoluo de nia komerca kaj puriga sistemo.
La unua versio de la arkitekturo de komerca kaj malplenigo de la sistemo estis konstruita sur la tielnomita Unikso-simila interago: komuna memoro, semaforoj kaj atendovicoj estis uzitaj, kaj ĉiu procezo konsistis el ununura fadeno. Tiu aliro estis ĝeneraligita en la fruaj 1990-aj jaroj.

La unua versio de la sistemo enhavis du nivelojn de Enirejo kaj centra servilo de la komerca sistemo. La laborfluo estis tia:

• La kliento sendas peton, kiu atingas la Enirejon. Ĝi kontrolas la validecon de la formato (sed ne la datumoj mem) kaj malakceptas malĝustajn transakciojn.
• Se informpeto estis sendita, ĝi estas ekzekutita loke; se ni parolas pri transakcio, tiam ĝi estas redirektita al la centra servilo.
• La komercmotoro tiam prilaboras la transakcion, modifas lokan memoron, kaj sendas respondon al la transakcio kaj la transakcio mem por reproduktado uzante apartan reproduktadmotoron.
• La Enirejo ricevas la respondon de la centra nodo kaj plusendas ĝin al la kliento.
• Post iom da tempo, la Enirejo ricevas la transakcion per la reprodukta mekanismo, kaj ĉi-foje ĝi ekzekutas ĝin loke, ŝanĝante siajn datumstrukturojn por ke la sekvaj informpetoj montru la plej novajn datumojn.

Fakte, ĝi priskribas reproduktan modelon, en kiu la Enirejo tute reproduktis la agojn faritajn en la komerca sistemo. Aparta reproduktadkanalo certigis ke transakcioj estis efektivigitaj en la sama ordo trans multoblaj alirnodoj.

Ĉar la kodo estis unufadena, klasika skemo kun procezforkoj estis uzata por servi multajn klientojn. Tamen, estis tre multekoste forki la tutan datumbazon, tiel ke malpezaj servprocezoj estis uzitaj kiuj kolektis pakaĵetojn de TCP-sesioj kaj transdonis ilin al unu atendovico (SystemV Message Queue). Gateway kaj Trade Engine funkciis nur kun ĉi tiu vosto, prenante transakciojn de tie por ekzekuto. Ne plu eblis sendi respondon al ĝi, ĉar ne estis klare, kiu serva procezo devus legi ĝin. Do ni uzis lertaĵon: ĉiu forkigita procezo kreis respondvicon por si, kaj kiam peto venis en la envenantan atendovicon, etikedo por la respondvico tuj estis aldonita al ĝi.

Konstante kopii grandajn kvantojn da datumoj de vosto al vosto kreis problemojn, precipe tipaj por informpetoj. Tial ni uzis alian lertaĵon: krom la respondvico, ĉiu procezo ankaŭ kreis komunan memoron (SystemV Shared Memory). La pakaĵoj mem estis metitaj en ĝin, kaj nur etikedo estis stokita en la atendovico, permesante al oni trovi la originan pakaĵon. Ĉi tio helpis stoki datumojn en la procesorkaŝmemoro.

SystemV IPC inkluzivas servaĵojn por vidi la staton de atendovico, memoro, kaj semaforobjektoj. Ni aktive uzis ĉi tion por kompreni kio okazas en la sistemo en aparta momento, kie pakoj akumuliĝis, kio estis blokita, ktp.

Unuaj modernigoj

Antaŭ ĉio, ni forigis la unu-procezan Enirejon. Ĝia signifa malavantaĝo estis ke ĝi povis pritrakti aŭ unu reproduktadtransakcion aŭ unu informpeton de kliento. Kaj kiam la ŝarĝo pliiĝas, Gateway daŭros pli longe por prilabori petojn kaj ne povos prilabori la reproduktan fluon. Krome, se la kliento sendis transakcion, tiam vi nur bezonas kontroli ĝian validecon kaj plusendi ĝin plu. Tial ni anstataŭigis la ununuran Gateway-procezon per multoblaj komponantoj, kiuj povas funkcii paralele: multfadenaj informoj kaj transakciaj procezoj kurantaj sendepende unu de la alia sur komuna memorareo uzante RW-ŝlosadon. Kaj samtempe ni enkondukis forsendajn kaj reproduktajn procezojn.

Efiko de Altfrekvenca Komerco

Ĉi-supra versio de la arkitekturo ekzistis ĝis 2010. Dume, ni ne plu kontentiĝis pri la agado de HP Superdome-serviloj. Krome, la PA-RISC-arkitekturo estis praktike morta; la vendisto ne ofertis iujn ajn signifajn ĝisdatigojn. Kiel rezulto, ni komencis moviĝi de HP UX/PA RISC al Linukso/x86. La transiro komenciĝis kun la adaptado de alirserviloj.

Kial ni devis denove ŝanĝi la arkitekturon? La fakto estas, ke altfrekvenca komerco signife ŝanĝis la ŝarĝan profilon sur la sistema kerno.

Ni diru, ke ni havas malgrandan transakcion, kiu kaŭzis gravan prezŝanĝon - iu aĉetis duonmiliardo da dolaroj. Post kelkaj milisekundoj, ĉiuj merkatpartoprenantoj rimarkas ĉi tion kaj komencas fari korekton. Nature, petoj viciĝas en grandega atendovico, kiun la sistemo daŭros longan tempon por forigi.

Je ĉi tiu intervalo de 50 ms, la averaĝa rapido estas ĉirkaŭ 16 mil transakcioj por sekundo. Se ni reduktas la fenestron al 20 ms, ni ricevas averaĝan rapidon de 90 mil transakcioj por sekundo, kun 200 mil transakcioj ĉe la pinto. Alivorte, la ŝarĝo ne estas konstanta, kun subitaj eksplodoj. Kaj la vico de petoj ĉiam devas esti procesita rapide.

Sed kial entute estas vico? Do, en nia ekzemplo, multaj uzantoj rimarkis la prezŝanĝon kaj sendis transakciojn laŭe. Ili venas al Gateway, ĝi seriigas ilin, starigas certan ordon kaj sendas ilin al la reto. Enkursigiloj miksas la pakaĵojn kaj plusendas ilin. Kies pako alvenis unue, tiu transakcio "gajnis". Kiel rezulto, interŝanĝaj klientoj komencis rimarki, ke se la sama transakcio estis sendita de pluraj Enirejoj, tiam la ŝancoj de ĝia rapida prilaborado pliiĝis. Baldaŭ, interŝanĝo-robotoj komencis bombardi Gateway per petoj, kaj lavango de transakcioj ekestis.

Nova raŭndo de evoluado

Post ampleksa testado kaj esplorado, ni ŝanĝis al la realtempa operaciuma kerno. Por tio ni elektis RedHat Enterprise MRG Linukson, kie MRG signifas mesaĝado en realtempa krado. La avantaĝo de realtempaj diakiloj estas, ke ili optimumigas la sistemon por la plej rapida ebla ekzekuto: ĉiuj procezoj estas vicigitaj en FIFO-vico, kernoj povas esti izolitaj, neniuj elĵetoj, ĉiuj transakcioj estas prilaboritaj en strikta sinsekvo.

Ruĝa - laborante kun vosto en regula kerno, verda - laboranta en realtempa kerno.

Sed atingi malaltan latentecon sur regulaj serviloj ne estas tiel facila:

• La SMI-reĝimo, kiu en la arkitekturo x86 estas la bazo por labori kun gravaj ekstercentraj, tre malhelpas. Prilaborado de ĉiaj aparataj eventoj kaj administrado de komponantoj kaj aparatoj estas farataj de la firmvaro en la tiel nomata travidebla SMI-reĝimo, en kiu la operaciumo tute ne vidas, kion la firmvaro faras. Kiel regulo, ĉiuj ĉefaj vendistoj ofertas specialajn etendaĵojn por firmware-serviloj, kiuj permesas redukti la kvanton de SMI-pretigo.
• Ne devus esti dinamika kontrolo de la frekvenco de procesoro, ĉi tio kondukas al plia malfunkcio.
• Kiam la dosiersistema protokolo estas forigita, certaj procezoj okazas en la kerno, kiuj kaŭzas neantaŭvideblajn prokrastojn.
• Vi devas atenti aferojn kiel CPU-Afineco, Interrupt-afineco, NUMA.

Mi devas diri, ke la temo pri agordo de Linuksa aparataro kaj kerno por realtempa prilaborado meritas apartan artikolon. Ni pasigis multan tempon eksperimentante kaj esplorante antaŭ ol ni atingis bonan rezulton.

Moviĝante de PA-RISC-serviloj al x86, ni praktike ne devis multe ŝanĝi la sisteman kodon, ni nur adaptis kaj reagordis ĝin. Samtempe ni riparis plurajn erarojn. Ekzemple, la sekvoj de la fakto ke PA RISC estis Big endian sistemo, kaj x86 estis Little endian sistemo, rapide ekaperis: ekzemple, datumoj estis legitaj malĝuste. La pli malfacila cimo estis tiu PA RISC uzas konsekvence konsekvenca (Sinsekve konsekvence) memoraliro, dum x86 povas reordigi legajn operaciojn, do kodo kiu estis absolute valida sur unu platformo rompiĝis sur alia.

Post ŝanĝado al x86, rendimento pliiĝis preskaŭ trioble, la averaĝa transakcia pretiga tempo malpliiĝis al 60 μs.

Ni nun rigardu pli detale, kiuj ŝlosilaj ŝanĝoj estis faritaj al la sistema arkitekturo.

Varma rezerva epopeo

Kiam ni ŝanĝis al varaj serviloj, ni konsciis, ke ili estas malpli fidindaj. Tial, kreante novan arkitekturon, ni apriore supozis la eblecon de fiasko de unu aŭ pluraj nodoj. Tial, varmega standby sistemo estis necesa kiu povus tre rapide ŝanĝi al rezervaj maŝinoj.

Krome, ekzistis aliaj postuloj:

• Sub neniu cirkonstanco vi devus perdi procesitajn transakciojn.
• La sistemo devas esti absolute travidebla al nia infrastrukturo.
• Klientoj ne devus vidi faligitajn ligojn.
• Rezervoj ne devus enkonduki gravan prokraston ĉar ĉi tio estas kritika faktoro por la interŝanĝo.

Kreinte varman standby-sistemon, ni ne konsideris tiajn scenarojn kiel duoblajn fiaskojn (ekzemple, la reto sur unu servilo ĉesis funkcii kaj la ĉefa servilo frostiĝis); ne konsideris la eblecon de eraroj en la programaro ĉar ili estas identigitaj dum testado; kaj ne konsideris la malĝustan funkciadon de la aparataro.

Kiel rezulto, ni venis al la sekva skemo:

• La ĉefa servilo interagis rekte kun la Gateway-serviloj.
• Ĉiuj transakcioj ricevitaj sur la ĉefa servilo estis tuj reproduktitaj al la rezerva servilo per aparta kanalo. La arbitracianto (Guberniestro) kunordigis la ŝanĝadon se iuj problemoj ekestis.

  

• La ĉefa servilo prilaboris ĉiun transakcion kaj atendis konfirmon de la rezerva servilo. Por minimumigi latencian, ni evitis atendi ke la transakcio finiĝos sur la rezerva servilo. Ĉar la tempo necesa por transakcio vojaĝi tra la reto estis komparebla al la ekzekuttempo, neniu kroma latenco estis aldonita.
• Ni nur povis kontroli la pretigan staton de la ĉefaj kaj rezervaj serviloj por la antaŭa transakcio, kaj la pretiga stato de la nuna transakcio estis nekonata. Ĉar ni ankoraŭ uzis unufadenajn procezojn, atendi respondon de Rezervo malrapidigus la tutan pretigan fluon, do ni faris akcepteblan kompromison: ni kontrolis la rezulton de la antaŭa transakcio.

La skemo funkciis jene.

Ni diru, ke la ĉefa servilo ĉesas respondi, sed la Enirejoj daŭre komunikiĝas. Tempoforiĝo okazas sur la rezerva servilo, ĝi kontaktas la Guberniestron, kiu asignas al ĝi la rolon de la ĉefa servilo, kaj ĉiuj Enirejoj ŝanĝas al la nova ĉefa servilo.

Se la ĉefa servilo revenas interrete, ĝi ankaŭ ekigas internan tempotempon, ĉar ne estis vokoj al la servilo de la Enirejo dum certa tempo. Tiam li ankaŭ turnas sin al la Guberniestro, kaj li ekskludas lin de la skemo. Kiel rezulto, la interŝanĝo funkcias kun unu servilo ĝis la fino de la komerca periodo. Ĉar la probableco de servila fiasko estas sufiĉe malalta, ĉi tiu skemo estis konsiderita sufiĉe akceptebla; ĝi ne enhavis kompleksan logikon kaj estis facile testi.

Daŭrigota.

fonto: www.habr.com