Hej alle! Mit navn er Sergey Kostanbaev, på børsen er jeg ved at udvikle kernen i handelssystemet.
Når Hollywood-film viser New York Stock Exchange, ser det altid sådan ud: folkemængder, alle råber noget, vifter med papirer, fuldstændig kaos sker. Dette er aldrig sket her på Moskva-børsen, fordi handel er blevet ført elektronisk lige fra begyndelsen og er baseret på to hovedplatforme - Spectra (valutamarked) og ASTS (valuta-, aktie- og pengemarked). Og i dag vil jeg tale om udviklingen af arkitekturen i ASTS-handels- og clearingsystemet, om forskellige løsninger og resultater. Historien bliver lang, så jeg var nødt til at dele den op i to dele.
Vi er en af de få børser i verden, der handler med aktiver af alle klasser og tilbyder et komplet udvalg af børstjenester. For eksempel var vi sidste år på andenpladsen i verden med hensyn til obligationshandel, 25. plads blandt alle børser, 13. plads i kapitalisering blandt offentlige børser.
For professionelle handelsdeltagere er sådanne parametre som responstid, stabilitet af tidsfordeling (jitter) og pålidelighed af hele komplekset kritiske. Vi behandler i øjeblikket titusinder af transaktioner om dagen. Behandlingen af hver transaktion af systemkernen tager snesevis af mikrosekunder. Selvfølgelig har mobiloperatører nytårsaften eller søgemaskiner selv en højere arbejdsbyrde end vores, men med hensyn til arbejdsbyrde, kombineret med de ovennævnte egenskaber, er det få, der kan måle sig med os, forekommer det mig. Samtidig er det vigtigt for os, at systemet ikke bremser et sekund, fungerer absolut stabilt, og alle brugere er på lige fod.
Lidt historie
I 1994 blev det australske ASTS-system lanceret på Moscow Interbank Currency Exchange (MICEX), og fra det øjeblik kan den russiske historie med elektronisk handel tælles. I 1998 blev børsarkitekturen moderniseret for at introducere internethandel. Siden da har implementeringshastigheden af nye løsninger og arkitektoniske ændringer i alle systemer og delsystemer kun taget fart.
I disse år arbejdede udvekslingssystemet på hi-end hardware - ultra-pålidelige HP Superdome 9000-servere (bygget på), hvor absolut alt blev duplikeret: input/output-undersystemer, netværk, RAM (faktisk var der et RAID-array af RAM), processorer (hot-swappable). Det var muligt at ændre enhver serverkomponent uden at stoppe maskinen. Vi stolede på disse enheder og betragtede dem som næsten fejlsikre. Operativsystemet var et Unix-lignende HP UX-system.
Men siden omkring 2010 er der opstået et fænomen kaldet højfrekvent handel (HFT), eller højfrekvent handel – kort sagt børsrobotter. På kun 2,5 år er belastningen på vores servere steget 140 gange.
Det var umuligt at modstå en sådan belastning med den gamle arkitektur og udstyr. Det var nødvendigt at tilpasse sig.
begynder
Forespørgsler til udvekslingssystemet kan opdeles i to typer:
- Transaktioner. Ønsker du at købe dollars, aktier eller andet, sender du en transaktion til handelssystemet og får svar om succes.
- Anmodninger om oplysninger. Hvis du ønsker at finde ud af den aktuelle pris, skal du se ordrebogen eller indeksene og derefter sende informationsanmodninger.
Skematisk kan systemets kerne opdeles i tre niveauer:
- Kundeniveauet, hvor mæglere og kunder arbejder. De interagerer alle med adgangsservere.
- Gateway-servere er cacheservere, der lokalt behandler alle informationsanmodninger. Vil du vide, hvilken pris Sberbank-aktier i øjeblikket handles til? Anmodningen går til adgangsserveren.
- Men hvis du vil købe aktier, så går anmodningen til den centrale server (Trade Engine). Der er en sådan server for hver type marked, de spiller en afgørende rolle, det er for dem, vi har skabt dette system.
Kernen i handelssystemet er en smart in-memory database, hvor alle transaktioner er byttetransaktioner. Basen blev skrevet i C, de eneste eksterne afhængigheder var libc-biblioteket, og der var ingen dynamisk hukommelsesallokering overhovedet. For at reducere behandlingstiden starter systemet med et statisk sæt af arrays og med statisk dataflytning: først bliver alle data for den aktuelle dag indlæst i hukommelsen, og der udføres ikke yderligere diskadgang, alt arbejde udføres kun i hukommelsen. Når systemet starter, er alle referencedata allerede sorteret, så søgningen fungerer meget effektivt og tager kort tid i runtime. Alle tabeller er lavet med påtrængende lister og træer til dynamiske datastrukturer, så de ikke kræver hukommelsesallokering ved kørsel.
Lad os kort gennemgå historien om udviklingen af vores handels- og clearingsystem.
Den første version af handels- og clearingsystemarkitekturen blev bygget på den såkaldte Unix-interaktion: delt hukommelse, semaforer og køer blev brugt, og hver proces bestod af en enkelt tråd. Denne tilgang var udbredt i begyndelsen af 1990'erne.
Den første version af systemet indeholdt to niveauer af Gateway og en central server for handelssystemet. Arbejdsgangen var sådan:
- Klienten sender en anmodning, som når gatewayen. Den kontrollerer gyldigheden af formatet (men ikke selve dataene) og afviser forkerte transaktioner.
- Hvis en informationsanmodning er blevet sendt, udføres den lokalt; hvis vi taler om en transaktion, så bliver den omdirigeret til den centrale server.
- Handelsmotoren behandler derefter transaktionen, ændrer lokal hukommelse og sender et svar til transaktionen og selve transaktionen til replikering ved hjælp af en separat replikeringsmotor.
- Gatewayen modtager svaret fra den centrale node og videresender det til klienten.
- Efter nogen tid modtager gatewayen transaktionen gennem replikeringsmekanismen, og denne gang udfører den den lokalt, og ændrer dens datastrukturer, så de næste informationsanmodninger viser de seneste data.
Faktisk beskriver den en replikeringsmodel, hvor Gateway fuldstændigt replikerede handlingerne udført i handelssystemet. En separat replikeringskanal sikrede, at transaktioner blev udført i samme rækkefølge på tværs af flere adgangsknuder.
Da koden var enkelttrådet, blev et klassisk skema med procesgafler brugt til at betjene mange kunder. Det var dog meget dyrt at gafle hele databasen, så der blev brugt lette serviceprocesser, der indsamlede pakker fra TCP-sessioner og overførte dem til én kø (SystemV Message Queue). Gateway og Trade Engine arbejdede kun med denne kø og tog transaktioner derfra til udførelse. Det var ikke længere muligt at sende et svar på det, fordi det ikke var klart, hvilken serviceproces der skulle læse den. Så vi tyede til et trick: hver splittet proces skabte en svarkø for sig selv, og når der kom en forespørgsel i den indkommende kø, blev der straks tilføjet et tag til svarkøen.
Konstant kopiering af store mængder data fra kø til kø skabte problemer, især typiske for informationsanmodninger. Derfor brugte vi et andet trick: Ud over svarkøen skabte hver proces også delt hukommelse (SystemV Shared Memory). Selve pakkerne blev placeret i den, og kun et mærke blev gemt i køen, så man kunne finde den originale pakke. Dette hjalp med at gemme data i processorens cache.
SystemV IPC indeholder værktøjer til at se tilstanden af kø-, hukommelses- og semaforobjekter. Vi brugte dette aktivt til at forstå, hvad der skete i systemet på et bestemt tidspunkt, hvor pakker akkumulerede, hvad der var blokeret osv.
Første moderniseringer
Først og fremmest slap vi af med single-proces Gateway. Dens væsentlige ulempe var, at den kunne håndtere enten én replikeringstransaktion eller én informationsanmodning fra en klient. Og efterhånden som belastningen øges, vil Gateway tage længere tid at behandle anmodninger og vil ikke være i stand til at behandle replikeringsflowet. Derudover, hvis klienten har sendt en transaktion, skal du kun kontrollere dens gyldighed og videresende den. Derfor erstattede vi den enkelte Gateway-proces med flere komponenter, der kan køre parallelt: multi-threaded information og transaktionsprocesser, der kører uafhængigt af hinanden på et delt hukommelsesområde ved hjælp af RW-låsning. Og samtidig introducerede vi afsendelses- og replikeringsprocesser.
Effekten af højfrekvent handel
Ovenstående version af arkitekturen eksisterede indtil 2010. I mellemtiden var vi ikke længere tilfredse med ydeevnen af HP Superdome-servere. Derudover var PA-RISC-arkitekturen praktisk talt død; leverandøren tilbød ingen væsentlige opdateringer. Som et resultat begyndte vi at flytte fra HP UX/PA RISC til Linux/x86. Overgangen begyndte med tilpasningen af adgangsservere.
Hvorfor skulle vi ændre arkitekturen igen? Faktum er, at højfrekvent handel har ændret belastningsprofilen på systemkernen markant.
Lad os sige, at vi har en lille transaktion, der forårsagede en betydelig prisændring - nogen købte en halv milliard dollars. Efter et par millisekunder bemærker alle markedsdeltagere dette og begynder at foretage en korrektion. Forespørgsler stiller sig naturligvis i en enorm kø, som systemet vil tage lang tid at rydde.
Ved dette 50 ms interval er den gennemsnitlige hastighed omkring 16 tusinde transaktioner i sekundet. Hvis vi reducerer vinduet til 20 ms, får vi en gennemsnitshastighed på 90 tusinde transaktioner i sekundet, med 200 tusinde transaktioner på toppen. Med andre ord er belastningen ikke konstant, med pludselige udbrud. Og køen af anmodninger skal altid behandles hurtigt.
Men hvorfor er der overhovedet kø? Så i vores eksempel bemærkede mange brugere prisændringen og sendte transaktioner i overensstemmelse hermed. De kommer til Gateway, den serialiserer dem, sætter en bestemt rækkefølge og sender dem til netværket. Routere blander pakkerne og sender dem videre. Hvis pakke ankom først, den transaktion "vandt". Som et resultat begyndte udvekslingsklienter at bemærke, at hvis den samme transaktion blev sendt fra flere gateways, så steg chancerne for hurtig behandling. Snart begyndte udvekslingsrobotter at bombardere Gateway med anmodninger, og en lavine af transaktioner opstod.
En ny runde af evolution
Efter omfattende test og research skiftede vi til real-time operativsystemkernen. Til dette valgte vi RedHat Enterprise MRG Linux, hvor MRG står for messaging real-time grid. Fordelen ved real-time patches er, at de optimerer systemet til den hurtigst mulige eksekvering: alle processer er linet op i en FIFO-kø, kerner kan isoleres, ingen udkast, alle transaktioner behandles i streng rækkefølge.
Rød - arbejder med en kø i en almindelig kerne, grøn - arbejder i en realtidskerne.
Men at opnå lav latenstid på almindelige servere er ikke så let:
- SMI-tilstanden, som i x86-arkitekturen er grundlaget for at arbejde med vigtige perifere enheder, forstyrrer i høj grad. Behandling af alle slags hardwarehændelser og styring af komponenter og enheder udføres af firmwaren i den såkaldte transparente SMI-tilstand, hvor operativsystemet slet ikke kan se, hvad firmwaren laver. Som regel tilbyder alle større leverandører specielle udvidelser til firmwareservere, der gør det muligt at reducere mængden af SMI-behandling.
- Der bør ikke være nogen dynamisk kontrol af processorfrekvensen, dette fører til yderligere nedetid.
- Når filsystemloggen tømmes, sker der visse processer i kernen, der forårsager uforudsigelige forsinkelser.
- Du skal være opmærksom på ting som CPU Affinity, Interrupt affinity, NUMA.
Jeg må sige, at emnet om opsætning af Linux-hardware og -kerne til realtidsbehandling fortjener en separat artikel. Vi brugte meget tid på at eksperimentere og researche, før vi opnåede et godt resultat.
Da vi flyttede fra PA-RISC-servere til x86, behøvede vi praktisk talt ikke at ændre systemkoden meget, vi tilpassede og omkonfigurerede den. Samtidig fik vi rettet flere fejl. For eksempel dukkede konsekvenserne af, at PA RISC var et Big endian-system, og x86 var et Little endian-system, hurtigt op: for eksempel blev data læst forkert. Den vanskeligere fejl var, at PA RISC bruger () hukommelsesadgang, hvorimod x86 kan omarrangere læseoperationer, så kode, der var absolut gyldig på én platform, blev ødelagt på en anden.
Efter skift til x86 steg ydeevnen næsten tre gange, den gennemsnitlige transaktionsbehandlingstid faldt til 60 μs.
Lad os nu se nærmere på, hvilke vigtige ændringer der er foretaget i systemarkitekturen.
Hot reserve-epos
Da vi skiftede til råvareservere, var vi klar over, at de var mindre pålidelige. Derfor, når vi oprettede en ny arkitektur, antog vi på forhånd muligheden for fejl i en eller flere noder. Derfor var der brug for et hot standby-system, der meget hurtigt kunne skifte til backup-maskiner.
Derudover var der andre krav:
- Du må under ingen omstændigheder miste behandlede transaktioner.
- Systemet skal være fuldstændig gennemsigtigt for vores infrastruktur.
- Klienter bør ikke se afbrudte forbindelser.
- Forbehold bør ikke medføre væsentlig forsinkelse, da dette er en kritisk faktor for udvekslingen.
Da vi oprettede et hot standby-system, betragtede vi ikke sådanne scenarier som dobbeltfejl (for eksempel holdt netværket på en server op med at fungere, og hovedserveren frøs); overvejede ikke muligheden for fejl i softwaren, fordi de er identificeret under test; og overvejede ikke den forkerte betjening af hardwaren.
Som et resultat kom vi frem til følgende ordning:
- Hovedserveren interagerede direkte med Gateway-serverne.
- Alle transaktioner modtaget på hovedserveren blev øjeblikkeligt replikeret til backupserveren via en separat kanal. Voldgiftsdommeren (guvernøren) koordinerede skiftet, hvis der opstod problemer.
- Hovedserveren behandlede hver transaktion og ventede på bekræftelse fra backupserveren. For at holde ventetiden på et minimum undgik vi at vente på, at transaktionen var fuldført på backupserveren. Da den tid, det tog for en transaktion at rejse på tværs af netværket, var sammenlignelig med udførelsestiden, blev der ikke tilføjet yderligere latens.
- Vi kunne kun kontrollere behandlingsstatussen for hoved- og backupserveren for den tidligere transaktion, og behandlingsstatussen for den aktuelle transaktion var ukendt. Da vi stadig brugte enkelttrådede processer, ville vente på et svar fra Backup have bremset hele behandlingsflowet, så vi indgik et rimeligt kompromis: vi tjekkede resultatet af den forrige transaktion.
Ordningen fungerede som følger.
Lad os sige, at hovedserveren holder op med at reagere, men Gateways fortsætter med at kommunikere. Der opstår en timeout på backupserveren, den kontakter guvernøren, som tildeler den rollen som hovedserveren, og alle Gateways skifter til den nye hovedserver.
Hvis hovedserveren kommer online igen, udløser det også en intern timeout, fordi der ikke har været nogen opkald til serveren fra gatewayen i et vist tidsrum. Så henvender han sig også til guvernøren, og han udelukker ham fra ordningen. Som et resultat fungerer børsen med én server indtil udgangen af handelsperioden. Da sandsynligheden for en serverfejl er ret lav, blev denne ordning betragtet som ganske acceptabel; den indeholdt ikke kompleks logik og var let at teste.
Fortsættes.
Kilde: www.habr.com