Evolucioni i arkitekturës së sistemit të tregtimit dhe pastrimit të Bursës së Moskës. Pjesa 1

Pershendetje te gjitheve! Emri im është Sergey Kostanbaev, në Bursë po zhvilloj thelbin e sistemit të tregtimit.

Kur filmat e Hollivudit tregojnë Bursën e Nju Jorkut, duket gjithmonë kështu: turma njerëzish, të gjithë bërtasin diçka, tundin letrat, kaos i plotë po ndodh. Kjo nuk ka ndodhur kurrë këtu në Bursën e Moskës, sepse tregtimi është kryer në mënyrë elektronike që në fillim dhe bazohet në dy platforma kryesore - Spectra (tregu Forex) dhe ASTS (këmbë valutore, aksione dhe treg parash). Dhe sot dua të flas për evolucionin e arkitekturës së sistemit të tregtimit dhe kleringut ASTS, për zgjidhje dhe gjetje të ndryshme. Historia do të jetë e gjatë, ndaj më duhej ta ndaja në dy pjesë.

Ne jemi një nga shkëmbimet e pakta në botë që tregtojmë aktive të të gjitha klasave dhe ofrojmë një gamë të plotë shërbimesh shkëmbimi. Për shembull, vitin e kaluar ne u renditëm e dyta në botë për sa i përket vëllimit të tregtimit të obligacioneve, vendi i 25-të në të gjitha bursat, vendi i 13-të në kapitalizimin midis bursave publike.

Për pjesëmarrësit profesionistë të tregtimit, parametra të tillë si koha e përgjigjes, stabiliteti i shpërndarjes së kohës (jitter) dhe besueshmëria e të gjithë kompleksit janë kritike. Aktualisht ne përpunojmë dhjetëra miliona transaksione në ditë. Përpunimi i çdo transaksioni nga kerneli i sistemit zgjat dhjetëra mikrosekonda. Sigurisht, operatorët celularë në natën e ndërrimit të viteve ose vetë motorët e kërkimit kanë një ngarkesë më të madhe se e jona, por përsa i përket ngarkesës, së bashku me karakteristikat e sipërpërmendura, pak mund të krahasohen me ne, më duket. Në të njëjtën kohë, është e rëndësishme për ne që sistemi të mos ngadalësohet për asnjë sekondë, të funksionojë absolutisht në mënyrë të qëndrueshme dhe të gjithë përdoruesit të jenë në pozitë të barabartë.

Pak histori

Në vitin 1994, sistemi australian ASTS u lançua në Shkëmbimin e Valutave Ndërbankare të Moskës (MICEX), dhe që nga ai moment mund të numërohet historia ruse e tregtisë elektronike. Në vitin 1998, arkitektura e shkëmbimeve u modernizua për të prezantuar tregtimin në internet. Që atëherë, shpejtësia e zbatimit të zgjidhjeve të reja dhe ndryshimeve arkitekturore në të gjitha sistemet dhe nënsistemet ka marrë vetëm vrull.

Në ato vite, sistemi i shkëmbimit funksiononte në pajisje të nivelit të lartë - serverë ultra të besueshëm HP Superdome 9000 (të ndërtuara në PA-RISC), në të cilin absolutisht gjithçka ishte dublikuar: nënsistemet hyrëse/dalëse, rrjeti, RAM (në fakt, kishte një grup RAID RAM), procesorë (të këmbyeshëm me nxehtësi). Ishte e mundur të ndryshohej çdo komponent i serverit pa ndalur makinën. Ne u mbështetëm në këto pajisje dhe i konsideruam ato praktikisht të sigurta për dështimin. Sistemi operativ ishte një sistem HP UX i ngjashëm me Unix-in.

Por që nga viti 2010, është shfaqur një fenomen i quajtur tregtimi me frekuencë të lartë (HFT), ose tregtimi me frekuencë të lartë - thënë thjesht, robotët e bursës. Në vetëm 2,5 vjet, ngarkesa në serverët tanë është rritur 140 herë.

Ishte e pamundur të përballosh një ngarkesë të tillë me arkitekturën dhe pajisjet e vjetra. Ishte e nevojshme të përshtatesh disi.

Fillim

Kërkesat për sistemin e shkëmbimit mund të ndahen në dy lloje:

• Transaksionet. Nëse dëshironi të blini dollarë, aksione ose diçka tjetër, ju dërgoni një transaksion në sistemin e tregtimit dhe merrni një përgjigje për suksesin.
• Kërkesat për informacion. Nëse dëshironi të zbuloni çmimin aktual, shikoni librin e porosive ose indekset, më pas dërgoni kërkesa për informacion.

Skematikisht, thelbi i sistemit mund të ndahet në tre nivele:

• Niveli i klientit, në të cilin punojnë ndërmjetësit dhe klientët. Ata të gjithë ndërveprojnë me serverët e aksesit.
• Serverët e portës janë serverë të memorizimit që përpunojnë në nivel lokal të gjitha kërkesat për informacion. Dëshironi të dini se me çfarë çmimi tregtohen aktualisht aksionet e Sberbank? Kërkesa shkon te serveri i aksesit.
• Por nëse doni të blini aksione, atëherë kërkesa shkon në serverin qendror (Trade Engine). Ekziston një server i tillë për çdo lloj tregu, ata luajnë një rol jetik, është për ta që ne krijuam këtë sistem.

Thelbi i sistemit të tregtimit është një bazë e të dhënave e zgjuar në memorie në të cilën të gjitha transaksionet janë transaksione shkëmbimi. Baza ishte shkruar në C, të vetmet varësi të jashtme ishin biblioteka libc dhe nuk kishte fare ndarje dinamike të memories. Për të reduktuar kohën e përpunimit, sistemi fillon me një grup statik vargjesh dhe me zhvendosje statike të të dhënave: së pari, të gjitha të dhënat për ditën aktuale ngarkohen në memorie dhe nuk kryhet asnjë akses i mëtejshëm në disk, e gjithë puna kryhet vetëm në memorie. Kur sistemi fillon, të gjitha të dhënat e referencës tashmë janë të renditura, kështu që kërkimi funksionon me shumë efikasitet dhe kërkon pak kohë në ekzekutim. Të gjitha tabelat janë bërë me lista ndërhyrëse dhe pemë për strukturat dinamike të të dhënave në mënyrë që ato të mos kërkojnë shpërndarjen e memories në kohën e ekzekutimit.

Le të kalojmë shkurtimisht historinë e zhvillimit të sistemit tonë të tregtimit dhe kleringut.
Versioni i parë i arkitekturës së sistemit të tregtimit dhe pastrimit u ndërtua mbi të ashtuquajturin ndërveprim Unix: u përdorën memorie të përbashkët, semaforë dhe radhë, dhe secili proces përbëhej nga një fije e vetme. Kjo qasje ishte e përhapur në fillim të viteve 1990.

Versioni i parë i sistemit përmbante dy nivele të Gateway dhe një server qendror të sistemit të tregtimit. Rrjedha e punës ishte si kjo:

• Klienti dërgon një kërkesë, e cila arrin në Gateway. Ai kontrollon vlefshmërinë e formatit (por jo vetë të dhënat) dhe refuzon transaksionet e pasakta.
• Nëse një kërkesë për informacion është dërguar, ajo ekzekutohet në nivel lokal; nëse po flasim për një transaksion, atëherë ai ridrejtohet në serverin qendror.
• Motori i tregtimit më pas përpunon transaksionin, modifikon memorien lokale dhe dërgon një përgjigje ndaj transaksionit dhe vetë transaksionit për përsëritje duke përdorur një motor të veçantë replikimi.
• Gateway merr përgjigjen nga nyja qendrore dhe ia përcjell klientit.
• Pas njëfarë kohe, Gateway merr transaksionin përmes mekanizmit të replikimit dhe këtë herë e ekzekuton atë në nivel lokal, duke ndryshuar strukturat e të dhënave në mënyrë që kërkesat e ardhshme të informacionit të shfaqin të dhënat më të fundit.

Në fakt, ai përshkruan një model riprodhimi në të cilin Gateway përsëriti plotësisht veprimet e kryera në sistemin e tregtimit. Një kanal i veçantë replikimi siguroi që transaksionet të ekzekutoheshin në të njëjtin rend nëpër nyje të shumta aksesi.

Meqenëse kodi ishte me një fillesë, një skemë klasike me forks procesi u përdor për t'i shërbyer shumë klientëve. Megjithatë, ishte shumë e kushtueshme për të forcuar të gjithë bazën e të dhënave, kështu që u përdorën procese të lehta shërbimi që mblidhnin paketat nga sesionet TCP dhe i transferonin ato në një radhë (Radha e mesazheve të SystemV). Gateway dhe Trade Engine punonin vetëm me këtë radhë, duke marrë transaksione nga atje për ekzekutim. Nuk ishte më e mundur të dërgohej një përgjigje për të, sepse nuk ishte e qartë se cili proces shërbimi duhet ta lexonte atë. Kështu që ne iu drejtuam një mashtrimi: çdo proces i degëzuar krijoi një radhë përgjigjeje për vete, dhe kur një kërkesë hynte në radhën hyrëse, menjëherë iu shtua një etiketë për radhën e përgjigjes.

Kopjimi i vazhdueshëm i sasive të mëdha të të dhënave nga radhë në radhë krijonte probleme, veçanërisht tipike për kërkesat për informacion. Prandaj, ne përdorëm një truk tjetër: përveç radhës së përgjigjes, çdo proces krijonte edhe memorie të përbashkët (SystemV Shared Memory). Vetë paketat u vendosën në të dhe vetëm një etiketë u ruajt në radhë, duke lejuar që dikush të gjejë paketën origjinale. Kjo ndihmoi në ruajtjen e të dhënave në cache të procesorit.

SystemV IPC përfshin shërbime për shikimin e gjendjes së radhës, memories dhe objekteve të semaforit. Ne e përdorëm këtë në mënyrë aktive për të kuptuar se çfarë po ndodhte në sistem në një moment të caktuar, ku u grumbulluan paketat, çfarë u bllokua, etj.

Modernizimet e para

Para së gjithash, ne hoqëm qafe portën me një proces të vetëm. Pengesa e tij e rëndësishme ishte se ai mund të trajtonte ose një transaksion replikimi ose një kërkesë informacioni nga një klient. Dhe ndërsa ngarkesa rritet, Gateway do të marrë më shumë kohë për të përpunuar kërkesat dhe nuk do të jetë në gjendje të përpunojë rrjedhën e përsëritjes. Përveç kësaj, nëse klienti dërgoi një transaksion, atëherë ju vetëm duhet të kontrolloni vlefshmërinë e tij dhe ta përcillni atë më tej. Prandaj, ne zëvendësuam procesin e vetëm Gateway me komponentë të shumtë që mund të funksionojnë paralelisht: informacioni me shumë fije dhe proceset e transaksionit që funksionojnë në mënyrë të pavarur nga njëri-tjetri në një zonë memorie të përbashkët duke përdorur mbylljen RW. Dhe në të njëjtën kohë ne prezantuam proceset e dërgimit dhe riprodhimit.

Ndikimi i tregtimit me frekuencë të lartë

Versioni i mësipërm i arkitekturës ekzistonte deri në vitin 2010. Ndërkohë, nuk ishim më të kënaqur me performancën e serverëve HP Superdome. Për më tepër, arkitektura PA-RISC ishte praktikisht e vdekur; shitësi nuk ofroi ndonjë përditësim domethënës. Si rezultat, ne filluam të lëvizim nga HP UX/PA RISC në Linux/x86. Tranzicioni filloi me përshtatjen e serverëve të aksesit.

Pse duhej të ndryshonim sërish arkitekturën? Fakti është se tregtimi me frekuencë të lartë ka ndryshuar ndjeshëm profilin e ngarkesës në bërthamën e sistemit.

Le të themi se kemi një transaksion të vogël që shkaktoi një ndryshim të rëndësishëm çmimi - dikush bleu gjysmë miliardë dollarë. Pas disa milisekondash, të gjithë pjesëmarrësit e tregut e vërejnë këtë dhe fillojnë të bëjnë një korrigjim. Natyrisht, kërkesat rreshtohen në një radhë të madhe, të cilën sistemi do t'i duhet shumë kohë për t'i pastruar.

Në këtë interval prej 50 ms, shpejtësia mesatare është rreth 16 mijë transaksione në sekondë. Nëse e zvogëlojmë dritaren në 20 ms, marrim një shpejtësi mesatare prej 90 mijë transaksionesh në sekondë, me 200 mijë transaksione në kulm. Me fjalë të tjera, ngarkesa nuk është konstante, me breshëri të papritura. Dhe radha e kërkesave duhet të përpunohet gjithmonë shpejt.

Por pse ka fare radhë? Pra, në shembullin tonë, shumë përdorues vunë re ndryshimin e çmimit dhe dërguan transaksione në përputhje me rrethanat. Ata vijnë në Gateway, i serializon, vendos një rend të caktuar dhe i dërgon në rrjet. Ruterat i përziejnë paketat dhe i përcjellin ato. Pakoja e të cilit mbërriti e para, ai transaksion "fitoi". Si rezultat, klientët e shkëmbimit filluan të vërejnë se nëse i njëjti transaksion dërgohej nga disa Gateways, atëherë shanset për përpunimin e tij të shpejtë rriteshin. Së shpejti, robotët e shkëmbimit filluan të bombardojnë Gateway me kërkesa dhe u ngrit një ortek transaksionesh.

Një raund i ri evolucioni

Pas testimeve dhe kërkimeve të gjera, ne kaluam në kernelin e sistemit operativ në kohë reale. Për këtë ne zgjodhëm RedHat Enterprise MRG Linux, ku MRG qëndron për rrjetin e mesazheve në kohë reale. Avantazhi i arnimeve në kohë reale është se ato optimizojnë sistemin për ekzekutimin më të shpejtë të mundshëm: të gjitha proceset janë të rreshtuara në një radhë FIFO, bërthamat mund të izolohen, nuk ka nxjerrje, të gjitha transaksionet përpunohen në sekuencë strikte.

E kuqe - duke punuar me një radhë në një kernel të rregullt, jeshile - duke punuar në një kernel në kohë reale.

Por arritja e vonesës së ulët në serverët e rregullt nuk është aq e lehtë:

• Modaliteti SMI, i cili në arkitekturën x86 është baza për të punuar me pajisje të rëndësishme periferike, ndërhyn shumë. Përpunimi i të gjitha llojeve të ngjarjeve harduerike dhe menaxhimi i komponentëve dhe pajisjeve kryhet nga firmware në të ashtuquajturin modalitet transparent SMI, në të cilin sistemi operativ nuk sheh fare se çfarë po bën firmware. Si rregull, të gjithë shitësit kryesorë ofrojnë shtesa speciale për serverët e firmuerit që lejojnë uljen e sasisë së përpunimit të SMI.
• Nuk duhet të ketë kontroll dinamik të frekuencës së procesorit, kjo çon në ndërprerje shtesë.
• Kur regjistri i sistemit të skedarëve fshihet, disa procese ndodhin në kernel që shkaktojnë vonesa të paparashikueshme.
• Duhet t'i kushtoni vëmendje gjërave si Afiniteti i CPU-së, Afiniteti i Ndërprerjes, NUMA.

Duhet të them që tema e konfigurimit të harduerit dhe kernelit Linux për përpunim në kohë reale meriton një artikull të veçantë. Kaluam shumë kohë duke eksperimentuar dhe hulumtuar përpara se të arrinim një rezultat të mirë.

Kur kaluam nga serverët PA-RISC në x86, praktikisht nuk na duhej të ndryshonim shumë kodin e sistemit, thjesht e përshtatëm dhe rikonfiguruam atë. Në të njëjtën kohë, ne rregulluam disa gabime. Për shembull, pasojat e faktit që PA RISC ishte një sistem endian i madh dhe x86 ishte një sistem endian i vogël, u shfaqën shpejt: për shembull, të dhënat u lexuan gabimisht. Gabimi më i ndërlikuar ishte që përdor PA RISC vazhdimisht konsistente (Në mënyrë të vazhdueshme konsistente) aksesi i memories, ndërsa x86 mund të riorganizojë operacionet e leximit, kështu që kodi që ishte absolutisht i vlefshëm në një platformë u prish në një tjetër.

Pas kalimit në x86, performanca u rrit pothuajse trefish, koha mesatare e përpunimit të transaksionit u ul në 60 μs.

Le të hedhim një vështrim më të afërt se çfarë ndryshimesh kryesore janë bërë në arkitekturën e sistemit.

Epika e nxehtë rezervë

Kur kaluam te serverët e mallrave, ne ishim të vetëdijshëm se ata ishin më pak të besueshëm. Prandaj, gjatë krijimit të një arkitekture të re, ne apriori supozuam mundësinë e dështimit të një ose më shumë nyjeve. Prandaj, nevojitej një sistem gatishmërie e nxehtë që mund të kalonte shumë shpejt në makinat rezervë.

Përveç kësaj, kishte kërkesa të tjera:

• Në asnjë rrethanë nuk duhet të humbni transaksionet e përpunuara.
• Sistemi duhet të jetë absolutisht transparent për infrastrukturën tonë.
• Klientët nuk duhet të shohin lidhjet e ndërprera.
• Rezervimet nuk duhet të sjellin vonesa të konsiderueshme sepse ky është një faktor kritik për shkëmbimin.

Kur krijuam një sistem gatishmërie të nxehtë, ne nuk i konsideruam skenarë të tillë si dështime të dyfishta (për shembull, rrjeti në një server ndaloi së punuari dhe serveri kryesor ngriu); nuk ka marrë parasysh mundësinë e gabimeve në softuer sepse ato janë identifikuar gjatë testimit; dhe nuk mori parasysh funksionimin e gabuar të harduerit.

Si rezultat, arritëm në skemën e mëposhtme:

• Serveri kryesor ndërveproi drejtpërdrejt me serverët Gateway.
• Të gjitha transaksionet e marra në serverin kryesor u përsëritën menjëherë në serverin rezervë përmes një kanali të veçantë. Arbitri (Guvernatori) koordinoi ndërrimin nëse lindte ndonjë problem.

  

• Serveri kryesor përpunoi çdo transaksion dhe priti konfirmimin nga serveri rezervë. Për të mbajtur vonesën në minimum, ne shmangëm pritjen që transaksioni të përfundonte në serverin rezervë. Meqenëse koha që iu desh për një transaksion për të udhëtuar nëpër rrjet ishte e krahasueshme me kohën e ekzekutimit, nuk u shtua asnjë vonesë shtesë.
• Mund të kontrollonim vetëm statusin e përpunimit të serverit kryesor dhe atij rezervë për transaksionin e mëparshëm dhe statusi i përpunimit të transaksionit aktual ishte i panjohur. Meqenëse ne ishim ende duke përdorur procese me një fillesë, pritja për një përgjigje nga Backup do të kishte ngadalësuar të gjithë rrjedhën e përpunimit, kështu që bëmë një kompromis të arsyeshëm: kontrolluam rezultatin e transaksionit të mëparshëm.

Skema funksionoi si më poshtë.

Le të themi se serveri kryesor nuk përgjigjet, por Gateways vazhdojnë të komunikojnë. Në serverin rezervë ndodh një afat kohor, ai kontakton Guvernatorin, i cili i cakton atij rolin e serverit kryesor dhe të gjitha Gateways kalojnë në serverin e ri kryesor.

Nëse serveri kryesor kthehet në linjë, ai gjithashtu shkakton një afat kohor të brendshëm, sepse nuk ka pasur asnjë thirrje në server nga Gateway për një kohë të caktuar. Më pas i drejtohet edhe Guvernatorit dhe ai e përjashton nga skema. Si rezultat, shkëmbimi funksionon me një server deri në fund të periudhës së tregtimit. Meqenëse probabiliteti i një dështimi të serverit është mjaft i ulët, kjo skemë u konsiderua mjaft e pranueshme; nuk përmbante logjikë komplekse dhe ishte e lehtë për t'u testuar.

Të vazhdohet.

Burimi: www.habr.com