Esblygiad pensaernïaeth system fasnachu a chlirio Cyfnewidfa Moscow. Rhan 1

Helo pawb! Fy enw i yw Sergey Kostanbaev, yn y Gyfnewidfa rwy'n datblygu craidd y system fasnachu.

Pan fydd ffilmiau Hollywood yn dangos Cyfnewidfa Stoc Efrog Newydd, mae bob amser yn edrych fel hyn: torfeydd o bobl, mae pawb yn gweiddi rhywbeth, yn chwifio papurau, mae anhrefn llwyr yn digwydd. Nid yw hyn erioed wedi digwydd yma ar Gyfnewidfa Moscow, oherwydd bod masnachu wedi'i gynnal yn electronig o'r cychwyn cyntaf ac mae'n seiliedig ar ddau brif lwyfan - Spectra (marchnad forex) ac ASTS (cyfnewidfa dramor, marchnad stoc ac arian). A heddiw rwyf am siarad am esblygiad pensaernïaeth system fasnachu a chlirio ASTS, am wahanol atebion a chanfyddiadau. Bydd y stori'n hir, felly roedd yn rhaid i mi ei thorri'n ddwy ran.

Ni yw un o'r ychydig gyfnewidfeydd yn y byd sy'n masnachu asedau o bob dosbarth ac yn darparu ystod lawn o wasanaethau cyfnewid. Er enghraifft, y llynedd rydym yn ail yn y byd o ran cyfaint masnachu bond, lle 25 ymhlith yr holl gyfnewidfeydd stoc, 13eg lle mewn cyfalafu ymhlith cyfnewidfeydd cyhoeddus.

Ar gyfer cyfranogwyr masnachu proffesiynol, mae paramedrau fel amser ymateb, sefydlogrwydd dosbarthiad amser (jitter) a dibynadwyedd y cyfadeilad cyfan yn hollbwysig. Ar hyn o bryd rydym yn prosesu degau o filiynau o drafodion y dydd. Mae prosesu pob trafodiad gan gnewyllyn y system yn cymryd degau o ficroeiliadau. Wrth gwrs, mae gan weithredwyr symudol ar Nos Galan neu beiriannau chwilio eu hunain lwyth gwaith uwch na'n rhai ni, ond o ran llwyth gwaith, ynghyd â'r nodweddion uchod, ychydig sy'n gallu cymharu â ni, mae'n ymddangos i mi. Ar yr un pryd, mae'n bwysig i ni nad yw'r system yn arafu am eiliad, yn gweithio'n gwbl sefydlog, a bod yr holl ddefnyddwyr ar yr un lefel.

Ychydig o hanes

Ym 1994, lansiwyd system ASTS Awstralia ar Gyfnewidfa Arian Rhwng Banciau Moscow (MICEX), ac o'r eiliad honno gellir cyfrif hanes masnachu electronig Rwsia. Ym 1998, moderneiddiwyd y bensaernïaeth gyfnewid i gyflwyno masnachu Rhyngrwyd. Ers hynny, dim ond momentwm y mae cyflymder gweithredu atebion newydd a newidiadau pensaernïol ym mhob system ac is-system wedi bod yn ei ennill.

Yn y blynyddoedd hynny, bu'r system gyfnewid yn gweithio ar galedwedd uwch - gweinyddwyr HP Superdome 9000 hynod ddibynadwy (wedi'u hadeiladu ar y PA-RISC), lle cafodd popeth ei ddyblygu: is-systemau mewnbwn / allbwn, rhwydwaith, RAM (mewn gwirionedd, roedd amrywiaeth RAID o RAM), proseswyr (poeth-swappable). Roedd yn bosibl newid unrhyw gydran gweinydd heb atal y peiriant. Roeddem yn dibynnu ar y dyfeisiau hyn ac yn eu hystyried bron yn methu'n ddiogel. Roedd y system weithredu yn system HP UX tebyg i Unix.

Ond ers tua 2010, mae ffenomen wedi dod i'r amlwg o'r enw masnachu amledd uchel (HFT), neu fasnachu amledd uchel - yn syml, robotiaid cyfnewid stoc. Mewn dim ond 2,5 mlynedd, mae'r llwyth ar ein gweinyddion wedi cynyddu 140 o weithiau.

Roedd yn amhosib gwrthsefyll y fath lwyth gyda'r hen bensaernïaeth a'r offer. Roedd angen addasu rhywsut.

Dechrau

Gellir rhannu ceisiadau i'r system gyfnewid yn ddau fath:

• Trafodion. Os ydych chi eisiau prynu doleri, cyfranddaliadau neu rywbeth arall, rydych chi'n anfon trafodiad i'r system fasnachu ac yn derbyn ymateb am lwyddiant.
• Ceisiadau am wybodaeth. Os ydych chi am ddarganfod y pris cyfredol, edrychwch ar y llyfr archebion neu'r mynegeion, yna anfonwch geisiadau am wybodaeth.

Yn sgematig, gellir rhannu craidd y system yn dair lefel:

• Y lefel cleient, y mae broceriaid a chleientiaid yn gweithio arni. Maent i gyd yn rhyngweithio â gweinyddwyr mynediad.
• Mae gweinyddwyr porth yn weinyddion caching sy'n prosesu pob cais am wybodaeth yn lleol. Ydych chi eisiau gwybod pa bris y mae cyfranddaliadau Sberbank yn masnachu arno ar hyn o bryd? Mae'r cais yn mynd i'r gweinydd mynediad.
• Ond os ydych chi am brynu cyfranddaliadau, yna mae'r cais yn mynd i'r gweinydd canolog (Trade Engine). Mae un gweinydd o'r fath ar gyfer pob math o farchnad, maen nhw'n chwarae rhan hanfodol, ac ar eu cyfer nhw y gwnaethom greu'r system hon.

Craidd y system fasnachu yw cronfa ddata cof glyfar lle mae'r holl drafodion yn drafodion cyfnewid. Ysgrifennwyd y sylfaen yn C, yr unig ddibyniaethau allanol oedd y llyfrgell libc ac nid oedd unrhyw ddyraniad cof deinamig o gwbl. Er mwyn lleihau amser prosesu, mae'r system yn dechrau gyda set statig o araeau a chydag adleoli data statig: yn gyntaf, mae'r holl ddata ar gyfer y diwrnod presennol yn cael ei lwytho i'r cof, ac ni pherfformir mynediad disg pellach, dim ond yn y cof y gwneir yr holl waith. Pan fydd y system yn cychwyn, mae'r holl ddata cyfeirio eisoes wedi'i ddidoli, felly mae'r chwiliad yn gweithio'n effeithlon iawn ac yn cymryd ychydig o amser mewn amser rhedeg. Gwneir pob tabl gyda rhestrau ymwthiol a choed ar gyfer strwythurau data deinamig fel nad oes angen dyraniad cof arnynt ar amser rhedeg.

Gadewch i ni fynd yn fyr dros hanes datblygiad ein system fasnachu a chlirio.
Adeiladwyd fersiwn gyntaf pensaernïaeth y system fasnachu a chlirio ar yr hyn a elwir yn ryngweithio Unix: defnyddiwyd cof a rennir, semafforau a chiwiau, ac roedd pob proses yn cynnwys un edefyn. Roedd y dull hwn yn gyffredin yn y 1990au cynnar.

Roedd fersiwn gyntaf y system yn cynnwys dwy lefel o Gateway a gweinydd canolog y system fasnachu. Roedd y llif gwaith fel hyn:

• Mae'r cleient yn anfon cais, sy'n cyrraedd y Porth. Mae'n gwirio dilysrwydd y fformat (ond nid y data ei hun) ac yn gwrthod trafodion anghywir.
• Os anfonwyd cais am wybodaeth, caiff ei weithredu'n lleol; os ydym yn sôn am drafodiad, yna caiff ei ailgyfeirio i'r gweinydd canolog.
• Yna mae'r peiriant masnachu yn prosesu'r trafodiad, yn addasu cof lleol, ac yn anfon ymateb i'r trafodiad a'r trafodiad ei hun i'w ddyblygu gan ddefnyddio peiriant dyblygu ar wahân.
• Mae'r Porth yn derbyn yr ymateb o'r nod canolog ac yn ei anfon ymlaen at y cleient.
• Ar ôl peth amser, mae'r Porth yn derbyn y trafodiad trwy'r mecanwaith atgynhyrchu, a'r tro hwn mae'n ei weithredu'n lleol, gan newid ei strwythurau data fel bod y ceisiadau gwybodaeth nesaf yn arddangos y data diweddaraf.

Mewn gwirionedd, mae'n disgrifio model atgynhyrchu lle'r oedd y Porth yn ailadrodd yn llwyr y gweithredoedd a gyflawnwyd yn y system fasnachu. Sicrhaodd sianel atgynhyrchu ar wahân fod trafodion yn cael eu cyflawni yn yr un drefn ar draws nodau mynediad lluosog.

Gan fod y cod yn un edau, defnyddiwyd cynllun clasurol gyda ffyrch proses i wasanaethu llawer o gleientiaid. Fodd bynnag, roedd yn ddrud iawn fforchio'r gronfa ddata gyfan, felly defnyddiwyd prosesau gwasanaeth ysgafn a oedd yn casglu pecynnau o sesiynau TCP a'u trosglwyddo i un ciw (Ciw Neges SystemV). Gweithiodd Gateway a Trade Engine gyda'r ciw hwn yn unig, gan gymryd trafodion oddi yno i'w gweithredu. Nid oedd yn bosibl anfon ymateb iddo mwyach, oherwydd nid oedd yn glir pa broses gwasanaeth a ddylai ei ddarllen. Felly fe wnaethom droi at dric: roedd pob proses fforchog yn creu ciw ymateb iddo'i hun, a phan ddaeth cais i mewn i'r ciw a oedd yn dod i mewn, ychwanegwyd tag ar gyfer y ciw ymateb ato ar unwaith.

Roedd copïo symiau mawr o ddata yn gyson o’r ciw i’r ciw yn creu problemau, yn arbennig o nodweddiadol ar gyfer ceisiadau am wybodaeth. Felly, fe wnaethom ddefnyddio tric arall: yn ychwanegol at y ciw ymateb, roedd pob proses hefyd yn creu cof a rennir (SystemV Shared Memory). Gosodwyd y pecynnau eu hunain ynddo, a dim ond tag oedd wedi'i storio yn y ciw, gan ganiatáu i un ddod o hyd i'r pecyn gwreiddiol. Roedd hyn yn helpu i storio data yn storfa'r prosesydd.

Mae SystemV IPC yn cynnwys cyfleustodau ar gyfer gweld cyflwr gwrthrychau ciw, cof a semaffor. Fe wnaethom ddefnyddio hwn yn weithredol i ddeall beth oedd yn digwydd yn y system ar adeg benodol, lle roedd pecynnau'n cronni, beth oedd wedi'i rwystro, ac ati.

Moderneiddio cyntaf

Yn gyntaf oll, cawsom wared ar y Porth proses sengl. Yr anfantais sylweddol oedd y gallai ymdrin â naill ai un trafodiad atgynhyrchu neu un cais am wybodaeth gan gleient. Ac wrth i'r llwyth gynyddu, bydd Gateway yn cymryd mwy o amser i brosesu ceisiadau ac ni fydd yn gallu prosesu'r llif atgynhyrchu. Yn ogystal, os anfonodd y cleient drafodiad, yna dim ond gwirio ei ddilysrwydd sydd ei angen arnoch a'i anfon ymlaen ymhellach. Felly, fe wnaethom ddisodli'r broses Porth sengl gyda chydrannau lluosog a all redeg yn gyfochrog: gwybodaeth aml-edau a phrosesau trafodion yn rhedeg yn annibynnol ar ei gilydd ar ardal cof a rennir gan ddefnyddio cloi RW. Ac ar yr un pryd, fe wnaethom gyflwyno prosesau anfon ac atgynhyrchu.

Effaith Masnachu Amlder Uchel

Roedd y fersiwn uchod o'r bensaernïaeth yn bodoli tan 2010. Yn y cyfamser, nid oeddem bellach yn fodlon â pherfformiad gweinyddwyr HP Superdome. Yn ogystal, roedd pensaernïaeth PA-RISC bron wedi marw; ni chynigiodd y gwerthwr unrhyw ddiweddariadau sylweddol. O ganlyniad, dechreuon ni symud o HP UX / PA RISC i Linux / x86. Dechreuodd y trawsnewid gydag addasu gweinyddwyr mynediad.

Pam roedd yn rhaid i ni newid y bensaernïaeth eto? Y ffaith yw bod masnachu amledd uchel wedi newid y proffil llwyth ar graidd y system yn sylweddol.

Gadewch i ni ddweud bod gennym drafodiad bach a achosodd newid pris sylweddol - prynodd rhywun hanner biliwn o ddoleri. Ar ôl cwpl o filieiliadau, mae holl gyfranogwyr y farchnad yn sylwi ar hyn ac yn dechrau gwneud cywiriad. Yn naturiol, mae ceisiadau mewn ciw enfawr, a bydd y system yn cymryd amser hir i'w glirio.

Ar yr egwyl 50 ms hwn, y cyflymder cyfartalog yw tua 16 mil o drafodion yr eiliad. Os byddwn yn lleihau'r ffenestr i 20 ms, rydym yn cael cyflymder cyfartalog o 90 mil o drafodion yr eiliad, gyda 200 mil o drafodion ar yr uchafbwynt. Mewn geiriau eraill, nid yw'r llwyth yn gyson, gyda hyrddiau sydyn. Ac mae'n rhaid prosesu'r ciw o geisiadau yn gyflym bob amser.

Ond pam fod yna giw o gwbl? Felly, yn ein hesiampl, sylwodd llawer o ddefnyddwyr y newid pris ac anfon trafodion yn unol â hynny. Maen nhw'n dod i Gateway, mae'n eu cyfresoli, yn gosod trefn benodol ac yn eu hanfon i'r rhwydwaith. Mae llwybryddion yn cymysgu'r pecynnau a'u hanfon ymlaen. Pecyn pwy gyrhaeddodd gyntaf, y trafodiad hwnnw “ennill”. O ganlyniad, dechreuodd cleientiaid cyfnewid sylwi, pe bai'r un trafodiad yn cael ei anfon o sawl Pyrth, yna cynyddodd y siawns o'i brosesu cyflym. Yn fuan, dechreuodd robotiaid cyfnewid peledu Gateway gyda cheisiadau, a chododd llu o drafodion.

Rownd newydd o esblygiad

Ar ôl profion ac ymchwil helaeth, fe wnaethom newid i gnewyllyn y system weithredu amser real. Ar gyfer hyn fe wnaethom ddewis RedHat Enterprise MRG Linux, lle mae MRG yn sefyll am grid negeseuon amser real. Mantais clytiau amser real yw eu bod yn gwneud y gorau o'r system ar gyfer y gweithrediad cyflymaf posibl: mae'r holl brosesau wedi'u gosod mewn ciw FIFO, gall creiddiau gael eu hynysu, dim alldafliad, mae'r holl drafodion yn cael eu prosesu mewn trefn gaeth.

Coch - gweithio gyda chiw mewn cnewyllyn rheolaidd, gwyrdd - gweithio mewn cnewyllyn amser real.

Ond nid yw hi mor hawdd bod yn hwyr ar weinyddion rheolaidd:

• Mae'r modd SMI, sydd yn y bensaernïaeth x86 yn sail ar gyfer gweithio gyda perifferolion pwysig, yn ymyrryd yn fawr. Perfformir prosesu pob math o ddigwyddiadau caledwedd a rheoli cydrannau a dyfeisiau gan y firmware yn y modd SMI tryloyw fel y'i gelwir, lle nad yw'r system weithredu yn gweld beth mae'r firmware yn ei wneud o gwbl. Fel rheol, mae pob gwerthwr mawr yn cynnig estyniadau arbennig ar gyfer gweinyddwyr firmware sy'n caniatáu lleihau faint o brosesu salwch meddwl difrifol.
• Ni ddylai fod unrhyw reolaeth ddeinamig ar amlder y prosesydd, mae hyn yn arwain at amser segur ychwanegol.
• Pan fydd log y system ffeiliau yn cael ei fflysio, mae rhai prosesau'n digwydd yn y cnewyllyn sy'n achosi oedi anrhagweladwy.
• Mae angen i chi dalu sylw i bethau fel Affinedd CPU, Affinedd Ymyriad, NUMA.

Rhaid imi ddweud bod y pwnc o sefydlu caledwedd a chnewyllyn Linux ar gyfer prosesu amser real yn haeddu erthygl ar wahân. Treulion ni lawer o amser yn arbrofi ac ymchwilio cyn i ni gael canlyniad da.

Wrth symud o weinyddion PA-RISC i x86, yn ymarferol nid oedd yn rhaid i ni newid cod y system rhyw lawer, fe wnaethom ei addasu a'i ail-gyflunio. Ar yr un pryd, rydym yn trwsio nifer o fygiau. Er enghraifft, daeth canlyniadau'r ffaith bod PA RISC yn system endian Fawr, a x86 yn system endian Bach, i'r wyneb yn gyflym: er enghraifft, darllenwyd data yn anghywir. Y byg anoddach oedd bod PA RISC yn ei ddefnyddio gyson gyson (Yn ddilyniannol gyson) mynediad cof, tra gall x86 aildrefnu gweithrediadau darllen, felly torrwyd cod a oedd yn gwbl ddilys ar un platfform ar lwyfan arall.

Ar ôl newid i x86, cynyddodd perfformiad bron i driphlyg, gostyngodd yr amser prosesu trafodion cyfartalog i 60 μs.

Gadewch i ni nawr edrych yn agosach ar ba newidiadau allweddol sydd wedi'u gwneud i bensaernïaeth y system.

epig wrth gefn poeth

Wrth newid i weinyddion nwyddau, roeddem yn ymwybodol eu bod yn llai dibynadwy. Felly, wrth greu pensaernïaeth newydd, rydym a priori wedi rhagdybio y posibilrwydd o fethiant un neu fwy o nodau. Felly, roedd angen system wrth gefn boeth a allai newid yn gyflym iawn i beiriannau wrth gefn.

Yn ogystal, roedd gofynion eraill:

• Ni ddylech golli trafodion wedi'u prosesu o dan unrhyw amgylchiadau.
• Rhaid i’r system fod yn gwbl dryloyw i’n seilwaith.
• Ni ddylai cleientiaid weld cysylltiadau wedi'u gollwng.
• Ni ddylai archebion achosi oedi sylweddol oherwydd mae hyn yn ffactor hollbwysig ar gyfer y cyfnewid.

Wrth greu system wrth gefn poeth, ni wnaethom ystyried senarios o'r fath fel methiannau dwbl (er enghraifft, rhoddodd y rhwydwaith ar un gweinydd y gorau i weithio a rhewodd y prif weinydd); nad oedd wedi ystyried y posibilrwydd o wallau yn y meddalwedd oherwydd eu bod yn cael eu nodi yn ystod y profion; ac nid oedd yn ystyried gweithrediad anghywir y caledwedd.

O ganlyniad, daethom at y cynllun canlynol:

• Roedd y prif weinydd yn rhyngweithio'n uniongyrchol â gweinyddwyr Gateway.
• Cafodd yr holl drafodion a dderbyniwyd ar y prif weinydd eu hailadrodd ar unwaith i'r gweinydd wrth gefn trwy sianel ar wahân. Cydlynodd y canolwr (Llywodraethwr) y newid pe bai unrhyw broblemau'n codi.

  

• Roedd y prif weinydd yn prosesu pob trafodiad ac yn aros am gadarnhad gan y gweinydd wrth gefn. Er mwyn cadw hwyrni i'r lleiafswm, gwnaethom osgoi aros i'r trafodiad gael ei gwblhau ar y gweinydd wrth gefn. Gan fod yr amser a gymerodd i drafodiad deithio ar draws y rhwydwaith yn debyg i'r amser gweithredu, ni ychwanegwyd unrhyw hwyrni ychwanegol.
• Dim ond statws prosesu'r prif weinyddion a gweinyddwyr wrth gefn ar gyfer y trafodiad blaenorol y gallem ei wirio, ac nid oedd statws prosesu'r trafodiad cyfredol yn hysbys. Gan ein bod yn dal i ddefnyddio prosesau un edau, byddai aros am ymateb gan Backup wedi arafu'r llif prosesu cyfan, felly gwnaethom gyfaddawd rhesymol: fe wnaethom wirio canlyniad y trafodiad blaenorol.

Roedd y cynllun yn gweithio fel a ganlyn.

Gadewch i ni ddweud bod y prif weinydd yn stopio ymateb, ond mae'r Pyrth yn parhau i gyfathrebu. Mae terfyn amser yn digwydd ar y gweinydd wrth gefn, mae'n cysylltu â'r Llywodraethwr, sy'n aseinio rôl y prif weinydd iddo, ac mae pob Pyrth yn newid i'r prif weinydd newydd.

Os daw'r prif weinydd yn ôl ar-lein, mae hefyd yn sbarduno terfyn amser mewnol, oherwydd ni fu unrhyw alwadau i'r gweinydd o'r Porth ers amser penodol. Yna mae hefyd yn troi at y Llywodraethwr, ac mae'n ei eithrio o'r cynllun. O ganlyniad, mae'r cyfnewid yn gweithio gydag un gweinydd tan ddiwedd y cyfnod masnachu. Gan fod y tebygolrwydd o fethiant gweinydd yn eithaf isel, ystyriwyd bod y cynllun hwn yn eithaf derbyniol; nid oedd yn cynnwys rhesymeg gymhleth ac roedd yn hawdd ei brofi.

I'w barhau.

Ffynhonnell: hab.com