Mageuzi ya usanifu wa mfumo wa biashara na kusafisha wa Soko la Moscow. Sehemu 1

Salaam wote! Jina langu ni Sergey Kostanbaev, katika Soko ninaendeleza msingi wa mfumo wa biashara.

Wakati filamu za Hollywood zinaonyesha Soko la Hisa la New York, daima inaonekana kama hii: umati wa watu, kila mtu anapiga kelele kitu, akipunga karatasi, machafuko kamili yanatokea. Hii haijawahi kutokea hapa kwenye Soko la Moscow, kwa sababu biashara imefanywa kwa umeme tangu mwanzo na inategemea majukwaa mawili kuu - Spectra (soko la forex) na ASTS (kubadilishana kwa kigeni, soko la hisa na fedha). Na leo nataka kuzungumza juu ya mageuzi ya usanifu wa mfumo wa biashara na kusafisha ASTS, kuhusu ufumbuzi na matokeo mbalimbali. Hadithi itakuwa ndefu, kwa hivyo nililazimika kuivunja katika sehemu mbili.

Sisi ni mojawapo ya mabadilishano machache duniani ambayo yanauza mali ya aina zote na hutoa huduma kamili za ubadilishanaji. Kwa mfano, mwaka jana tulishika nafasi ya pili duniani kwa kiasi cha biashara ya dhamana, nafasi ya 25 kati ya soko zote za hisa, nafasi ya 13 katika mtaji kati ya soko la hisa la umma.

Kwa washiriki wa biashara ya kitaalamu, vigezo kama vile muda wa majibu, uthabiti wa usambazaji wa muda (jitter) na kutegemewa kwa tata nzima ni muhimu. Kwa sasa tunachakata makumi ya mamilioni ya miamala kwa siku. Uchakataji wa kila shughuli na kernel ya mfumo huchukua makumi ya sekunde ndogo. Kwa kweli, waendeshaji wa rununu kwenye Hawa ya Mwaka Mpya au injini za utaftaji zenyewe zina mzigo mkubwa zaidi kuliko wetu, lakini kwa suala la mzigo wa kazi, pamoja na sifa zilizotaja hapo juu, wachache wanaweza kulinganisha na sisi, inaonekana kwangu. Wakati huo huo, ni muhimu kwetu kwamba mfumo haupunguzi kwa sekunde, hufanya kazi kwa utulivu kabisa, na watumiaji wote wako kwa usawa.

Historia kidogo

Mnamo 1994, mfumo wa ASTS wa Australia ulizinduliwa kwenye Soko la Fedha la Interbank la Moscow (MICEX), na kutoka wakati huo historia ya Kirusi ya biashara ya elektroniki inaweza kuhesabiwa. Mnamo 1998, usanifu wa kubadilishana ulifanywa kisasa ili kuanzisha biashara ya mtandao. Tangu wakati huo, kasi ya utekelezaji wa ufumbuzi mpya na mabadiliko ya usanifu katika mifumo yote na mifumo ndogo imekuwa tu kupata kasi.

Katika miaka hiyo, mfumo wa kubadilishana ulifanya kazi kwenye vifaa vya mwisho - seva za kuaminika za HP Superdome 9000 (zilizojengwa juu ya PA-RISC), ambayo kila kitu kilirudiwa: mifumo ndogo ya pembejeo / pato, mtandao, RAM (kwa kweli, kulikuwa na safu ya RAID ya RAM), wasindikaji (wanaobadilisha moto). Iliwezekana kubadilisha sehemu yoyote ya seva bila kusimamisha mashine. Tulitegemea vifaa hivi na tukavichukulia kuwa ni salama kabisa. Mfumo wa uendeshaji ulikuwa mfumo wa Unix-kama HP UX.

Lakini tangu mwaka wa 2010, jambo limeibuka liitwalo high-frequency trading (HFT), au biashara ya masafa ya juu - kwa urahisi, roboti za kubadilishana hisa. Katika miaka 2,5 tu, mzigo kwenye seva zetu umeongezeka mara 140.

Haikuwezekana kuhimili mzigo kama huo na usanifu wa zamani na vifaa. Ilikuwa ni lazima kwa namna fulani kukabiliana.

mwanzo

Maombi kwa mfumo wa kubadilishana yanaweza kugawanywa katika aina mbili:

• Shughuli. Ikiwa unataka kununua dola, hisa au kitu kingine, unatuma shughuli kwenye mfumo wa biashara na kupokea jibu kuhusu mafanikio.
• Maombi ya habari. Ikiwa unataka kujua bei ya sasa, tazama kitabu cha agizo au fahirisi, kisha utume maombi ya habari.

Kwa utaratibu, msingi wa mfumo unaweza kugawanywa katika viwango vitatu:

• Kiwango cha mteja, ambapo madalali na wateja hufanya kazi. Wote huingiliana na seva za ufikiaji.
• Seva za lango ni seva za akiba ambazo huchakata maombi yote ya habari ndani ya nchi. Je! ungependa kujua hisa za Sberbank zinafanya biashara kwa bei gani kwa sasa? Ombi huenda kwa seva ya ufikiaji.
• Lakini ikiwa unataka kununua hisa, basi ombi huenda kwa seva kuu (Injini ya Biashara). Kuna seva moja kama hiyo kwa kila aina ya soko, ina jukumu muhimu, ni kwa ajili yao kwamba tumeunda mfumo huu.

Msingi wa mfumo wa biashara ni hifadhidata ya ujanja ya kumbukumbu ambayo shughuli zote ni shughuli za kubadilishana. Msingi uliandikwa kwa C, utegemezi pekee wa nje ulikuwa maktaba ya libc na hakukuwa na mgao wa kumbukumbu wa nguvu hata kidogo. Ili kupunguza muda wa usindikaji, mfumo huanza na seti ya tuli ya safu na uhamishaji wa data tuli: kwanza, data zote za siku ya sasa zimewekwa kwenye kumbukumbu, na hakuna ufikiaji zaidi wa diski unafanywa, kazi yote inafanywa tu kwenye kumbukumbu. Mfumo unapoanza, data zote za marejeleo tayari zimepangwa, kwa hivyo utafutaji hufanya kazi kwa ufanisi sana na huchukua muda kidogo katika muda wa utekelezaji. Majedwali yote yameundwa kwa orodha na miti inayoingilia kati kwa miundo thabiti ya data ili zisihitaji mgao wa kumbukumbu wakati wa utekelezaji.

Hebu tuchunguze kwa ufupi historia ya maendeleo ya mfumo wetu wa biashara na kusafisha.
Toleo la kwanza la usanifu wa mfumo wa biashara na kusafisha ulijengwa juu ya kinachojulikana mwingiliano wa Unix: kumbukumbu ya pamoja, semaphores na foleni zilitumiwa, na kila mchakato ulikuwa na thread moja. Mbinu hii ilikuwa imeenea katika miaka ya mapema ya 1990.

Toleo la kwanza la mfumo lilikuwa na viwango viwili vya Gateway na seva kuu ya mfumo wa biashara. Mtiririko wa kazi ulikuwa kama hii:

• Mteja hutuma ombi, ambalo hufikia Lango. Hukagua uhalali wa umbizo (lakini si data yenyewe) na kukataa miamala isiyo sahihi.
• Ikiwa ombi la habari limetumwa, linatekelezwa ndani ya nchi; ikiwa tunazungumza juu ya shughuli, basi inaelekezwa kwa seva kuu.
• Injini ya biashara kisha huchakata muamala, kurekebisha kumbukumbu ya ndani, na kutuma jibu kwa muamala na muamala wenyewe kwa urudufishaji kwa kutumia injini tofauti ya urudufishaji.
• Lango hupokea jibu kutoka kwa nodi ya kati na kuipeleka kwa mteja.
• Baada ya muda fulani, Gateway hupokea muamala kupitia utaratibu wa urudufishaji, na wakati huu huitekeleza ndani ya nchi, ikibadilisha miundo yake ya data ili maombi ya taarifa inayofuata yaonyeshe data ya hivi punde.

Kwa kweli, inaelezea mfano wa kuiga ambayo Gateway iliiga kabisa vitendo vilivyofanywa katika mfumo wa biashara. Njia tofauti ya urudufishaji ilihakikisha kuwa miamala ilitekelezwa kwa mpangilio uleule katika sehemu nyingi za ufikiaji.

Kwa kuwa msimbo ulikuwa wa nyuzi moja, mpango wa kawaida wenye uma wa mchakato ulitumiwa kuwahudumia wateja wengi. Hata hivyo, ilikuwa ghali sana kuweka hifadhidata nzima, kwa hivyo michakato ya huduma nyepesi ilitumiwa ambayo ilikusanya pakiti kutoka kwa vikao vya TCP na kuzihamisha kwenye foleni moja (Foleni ya Ujumbe wa Mfumo wa V). Lango na Injini ya Biashara ilifanya kazi tu na foleni hii, ikichukua shughuli kutoka hapo kwa utekelezaji. Haikuwezekana tena kutuma jibu kwake, kwa sababu haikuwa wazi ni mchakato gani wa huduma unapaswa kuisoma. Kwa hivyo tuliamua hila: kila mchakato uliogawanyika uliunda foleni ya majibu yenyewe, na wakati ombi lilipoingia kwenye foleni inayoingia, lebo ya foleni ya majibu iliongezwa mara moja.

Kunakili mara kwa mara kiasi kikubwa cha data kutoka kwa foleni hadi kwenye foleni kuliunda matatizo, hasa ya kawaida kwa maombi ya habari. Kwa hiyo, tulitumia hila nyingine: pamoja na foleni ya majibu, kila mchakato pia uliunda kumbukumbu iliyoshirikiwa (SystemV Shared Kumbukumbu). Vifurushi wenyewe viliwekwa ndani yake, na tag tu ilihifadhiwa kwenye foleni, ikiruhusu mtu kupata kifurushi cha asili. Hii ilisaidia kuhifadhi data kwenye kashe ya kichakataji.

SystemV IPC inajumuisha huduma za kutazama hali ya foleni, kumbukumbu, na vitu vya semaphore. Tulitumia kikamilifu hii kuelewa kile kilichokuwa kikitokea kwenye mfumo kwa wakati fulani, ambapo pakiti zilikusanyika, ni nini kilichozuiwa, nk.

Uboreshaji wa kwanza

Kwanza kabisa, tuliondoa Gateway ya mchakato mmoja. Upungufu wake muhimu ulikuwa kwamba inaweza kushughulikia muamala mmoja wa urudufishaji au ombi moja la habari kutoka kwa mteja. Na kadiri mzigo unavyoongezeka, Gateway itachukua muda mrefu kushughulikia maombi na haitaweza kushughulikia mtiririko wa urudufishaji. Kwa kuongeza, ikiwa mteja alituma shughuli, basi unahitaji tu kuangalia uhalali wake na kuipeleka zaidi. Kwa hivyo, tulibadilisha mchakato mmoja wa Gateway na vipengee vingi vinavyoweza kufanya kazi sambamba: maelezo yenye nyuzi nyingi na michakato ya muamala inayoendeshwa kivyake kwenye eneo la kumbukumbu iliyoshirikiwa kwa kutumia kufuli kwa RW. Na wakati huo huo tulianzisha michakato ya kupeleka na kurudia.

Athari za Uuzaji wa Masafa ya Juu

Toleo la hapo juu la usanifu lilikuwepo hadi 2010. Wakati huo huo, hatukuridhika tena na utendakazi wa seva za HP Superdome. Kwa kuongezea, usanifu wa PA-RISC ulikuwa karibu kufa; muuzaji hakutoa sasisho zozote muhimu. Kwa hiyo, tulianza kuhama kutoka HP UX/PA RISC hadi Linux/x86. Mpito ulianza na urekebishaji wa seva za ufikiaji.

Kwa nini tulilazimika kubadilisha usanifu tena? Ukweli ni kwamba biashara ya juu-frequency imebadilisha kwa kiasi kikubwa wasifu wa mzigo kwenye msingi wa mfumo.

Wacha tuseme tuna muamala mdogo ambao ulisababisha mabadiliko makubwa ya bei - mtu alinunua dola nusu bilioni. Baada ya milisekunde kadhaa, washiriki wote wa soko wanaona hili na kuanza kufanya masahihisho. Kwa kawaida, maombi yanajipanga kwenye foleni kubwa, ambayo mfumo utachukua muda mrefu kufuta.

Katika muda huu wa 50 ms, kasi ya wastani ni kuhusu shughuli elfu 16 kwa sekunde. Ikiwa tunapunguza dirisha hadi 20 ms, tunapata kasi ya wastani ya shughuli elfu 90 kwa pili, na shughuli 200 kwenye kilele. Kwa maneno mengine, mzigo sio mara kwa mara, na kupasuka kwa ghafla. Na foleni ya maombi lazima ishughulikiwe haraka.

Lakini kwa nini kuna foleni kabisa? Kwa hivyo, katika mfano wetu, watumiaji wengi waliona mabadiliko ya bei na kutuma shughuli ipasavyo. Wanakuja Gateway, inawasasisha, kuweka agizo fulani na kuwatuma kwa mtandao. Vipanga njia huchanganya pakiti na kuzipeleka mbele. Ambao kifurushi aliwasili kwanza, kwamba shughuli "alishinda". Kama matokeo, wateja wa kubadilishana walianza kugundua kuwa ikiwa shughuli hiyo hiyo ilitumwa kutoka kwa Gateways kadhaa, basi nafasi za usindikaji wake wa haraka ziliongezeka. Hivi karibuni, roboti za kubadilishana zilianza kushambulia Gateway na maombi, na shughuli nyingi zikaibuka.

Mzunguko mpya wa mageuzi

Baada ya majaribio ya kina na utafiti, tulibadilisha kernel ya mfumo wa uendeshaji wa wakati halisi. Kwa hili tulichagua RedHat Enterprise MRG Linux, ambapo MRG inasimamia ujumbe wa gridi ya wakati halisi. Faida ya viraka vya wakati halisi ni kwamba wanaboresha mfumo kwa utekelezaji wa haraka iwezekanavyo: michakato yote imewekwa kwenye foleni ya FIFO, cores zinaweza kutengwa, hakuna ejections, shughuli zote zinachakatwa kwa mlolongo mkali.

Nyekundu - kufanya kazi na foleni katika kernel ya kawaida, kijani - kufanya kazi katika kernel ya muda halisi.

Lakini kufikia latency ya chini kwenye seva za kawaida sio rahisi sana:

• Hali ya SMI, ambayo katika usanifu wa x86 ni msingi wa kufanya kazi na pembeni muhimu, huingilia sana. Usindikaji wa kila aina ya matukio ya vifaa na usimamizi wa vipengele na vifaa hufanywa na firmware katika kinachojulikana kama hali ya uwazi ya SMI, ambayo mfumo wa uendeshaji hauoni kile firmware inafanya wakati wote. Kama sheria, wachuuzi wote wakuu hutoa upanuzi maalum kwa seva za firmware zinazoruhusu kupunguza kiasi cha usindikaji wa SMI.
• Haipaswi kuwa na udhibiti wa nguvu wa mzunguko wa processor, hii inasababisha kupungua kwa ziada.
• Wakati logi ya mfumo wa faili inafutwa, michakato fulani hutokea kwenye kernel ambayo husababisha ucheleweshaji usiotabirika.
• Unahitaji kuzingatia mambo kama vile Uhusiano wa CPU, Uhusiano wa Kukatiza, NUMA.

Lazima niseme kwamba mada ya kuanzisha vifaa vya Linux na kernel kwa usindikaji wa wakati halisi inastahili makala tofauti. Tulitumia muda mwingi kufanya majaribio na kutafiti kabla ya kupata matokeo mazuri.

Wakati wa kuhama kutoka kwa seva za PA-RISC hadi x86, kwa kweli hatukuhitaji kubadilisha sana msimbo wa mfumo, tuliibadilisha na kuiweka upya. Wakati huo huo, tulirekebisha mende kadhaa. Kwa mfano, matokeo ya ukweli kwamba PA RISC ilikuwa mfumo Mkubwa wa endian, na x86 ilikuwa mfumo mdogo wa endian, ulijitokeza haraka: kwa mfano, data ilisomwa vibaya. Mdudu mgumu zaidi ni kwamba PA RISC hutumia thabiti (Inalingana kwa mpangilio) ufikiaji wa kumbukumbu, wakati x86 inaweza kupanga upya shughuli za kusoma, kwa hivyo nambari ambayo ilikuwa halali kwenye jukwaa moja ilivunjwa kwenye nyingine.

Baada ya kubadili hadi x86, utendakazi uliongezeka karibu mara tatu, muda wa wastani wa usindikaji wa shughuli ulipungua hadi 60 μs.

Hebu sasa tuchunguze kwa undani zaidi ni mabadiliko gani muhimu yamefanywa kwa usanifu wa mfumo.

Epic hifadhi ya moto

Wakati wa kubadilisha seva za bidhaa, tulijua kuwa haziaminiki sana. Kwa hiyo, wakati wa kuunda usanifu mpya, sisi priori tulidhani uwezekano wa kushindwa kwa nodes moja au zaidi. Kwa hivyo, mfumo wa kusubiri moto ulihitajika ambao ungeweza kubadili haraka kwa mashine za chelezo.

Kwa kuongeza, kulikuwa na mahitaji mengine:

• Kwa hali yoyote usipoteze shughuli zilizochakatwa.
• Mfumo lazima uwe wazi kabisa kwa miundombinu yetu.
• Wateja hawapaswi kuona miunganisho iliyoshuka.
• Kuweka nafasi hakupaswi kuleta ucheleweshaji mkubwa kwa sababu hii ni sababu muhimu kwa ubadilishanaji.

Wakati wa kuunda mfumo wa kusubiri moto, hatukuzingatia hali kama vile kushindwa mara mbili (kwa mfano, mtandao kwenye seva moja uliacha kufanya kazi na seva kuu iliganda); hawakuzingatia uwezekano wa makosa katika programu kwa sababu yanatambuliwa wakati wa kupima; na haukuzingatia uendeshaji usio sahihi wa vifaa.

Kama matokeo, tulikuja kwa mpango ufuatao:

• Seva kuu iliingiliana moja kwa moja na seva za Gateway.
• Shughuli zote zilizopokelewa kwenye seva kuu zilinakiliwa papo hapo kwa seva mbadala kupitia kituo tofauti. Msuluhishi (Gavana) aliratibu ubadilishaji ikiwa shida yoyote itatokea.

  

• Seva kuu ilichakata kila shughuli na kusubiri uthibitisho kutoka kwa seva ya chelezo. Ili kupunguza muda wa kusubiri, tuliepuka kusubiri shughuli ikamilike kwenye seva mbadala. Kwa kuwa muda uliochukua kwa shughuli ya kusafiri kwenye mtandao ulilinganishwa na muda wa utekelezaji, hakuna muda wa ziada wa kusubiri ulioongezwa.
• Tunaweza tu kuangalia hali ya uchakataji wa seva kuu na chelezo kwa shughuli ya awali, na hali ya uchakataji wa shughuli ya sasa haikujulikana. Kwa kuwa bado tulikuwa tunatumia michakato yenye uzi mmoja, kungoja jibu kutoka kwa Hifadhi Nakala kungepunguza kasi ya uchakataji mzima, kwa hivyo tulifanya maelewano yanayofaa: tuliangalia matokeo ya shughuli ya awali.

Mpango huo ulifanya kazi kama ifuatavyo.

Wacha tuseme seva kuu inacha kujibu, lakini Njia zinaendelea kuwasiliana. Muda wa kuisha hutokea kwenye seva ya chelezo, huwasiliana na Gavana, ambaye huipa jukumu la seva kuu, na Gateways zote hubadilisha hadi seva kuu mpya.

Ikiwa seva kuu itarudi mkondoni, pia husababisha kuisha kwa muda wa ndani, kwa sababu kumekuwa hakuna simu kwa seva kutoka kwa Lango kwa muda fulani. Kisha pia anamgeukia Gavana, naye anamtenga na mpango huo. Matokeo yake, ubadilishanaji hufanya kazi na seva moja hadi mwisho wa kipindi cha biashara. Kwa kuwa uwezekano wa hitilafu ya seva ni mdogo sana, mpango huu ulichukuliwa kuwa unakubalika kabisa; haukuwa na mantiki changamano na ilikuwa rahisi kujaribu.

Ili kuendelea.

Chanzo: mapenzi.com