Evolutioun vun der Architektur vum Handel a Clearing System vun der Moskauer Exchange. Deel 1

Evolutioun vun der Architektur vum Handel a Clearing System vun der Moskauer Exchange. Deel 1

Moien alleguer! Mäin Numm ass Sergey Kostanbaev, op der Exchange entwéckelen ech de Kär vum Handelssystem.

Wann Hollywood Filmer d'New York Bourse weisen, gesäit et ëmmer esou aus: Vill Leit, jidderee jäizt eppes, wackelt Pabeieren, e komplette Chaos geschitt. Dëst ass ni hei op der Moskauer Exchange geschitt, well den Handel vun Ufank un elektronesch duerchgefouert gouf a baséiert op zwou Haaptplattformen - Spectra (Forex Maart) an ASTS (Austausch, Bourse a Geldmaart). An haut wëll ech iwwer d'Evolutioun vun der Architektur vum ASTS Handels- a Clearingsystem schwätzen, iwwer verschidde Léisungen an Erkenntnisser. D'Geschicht wäert laang sinn, also hunn ech se an zwee Deeler missen opbriechen.

Mir sinn ee vun de wéinegen Austausch op der Welt, déi Verméigen vun alle Klassen handelt an eng ganz Palette vun Austauschservicer ubitt. Zum Beispill, d'lescht Joer si mir op der zweeter Plaz op der Welt a punkto Obligatiounshandelsvolumen, 25. Plaz ënner all Bourse, 13. Plaz an der Kapitaliséierung tëscht den ëffentlechen Austausch.

Evolutioun vun der Architektur vum Handel a Clearing System vun der Moskauer Exchange. Deel 1

Fir professionell Handelsparticipanten sinn esou Parameteren wéi d'Äntwertzäit, d'Stabilitéit vun der Zäitverdeelung (Jitter) an d'Zouverlässegkeet vum ganze Komplex kritesch. Mir veraarbecht de Moment zéngdausende vu Millioune Transaktiounen pro Dag. D'Veraarbechtung vun all Transaktioun vum Systemkär dauert Zénger vu Mikrosekonnen. Selbstverständlech hunn d'Handybetreiber op Silvester oder d'Sichmaschinne selwer eng méi héich Aarbechtsbelaaschtung wéi eis, awer wat d'Aarbechtslaascht ugeet, gekoppelt mat den uewe genannten Charakteristiken, kënne wéineg mat eis vergläichen, et schéngt mir. Zur selwechter Zäit ass et wichteg fir eis datt de System net fir eng Sekonn verlangsamt, absolut stabil funktionnéiert an all Benotzer op gläiche Féiss sinn.

E bësse Geschicht

Am Joer 1994 gouf den australesche ASTS System op der Moskauer Interbank Währungsaustausch (MICEX) gestart, a vun deem Moment kann d'russesch Geschicht vum elektroneschen Handel gezielt ginn. 1998 gouf d'Austauscharchitektur moderniséiert fir den Internethandel anzeféieren. Zënterhier ass d'Geschwindegkeet vun der Ëmsetzung vun neie Léisungen an architektonesche Verännerungen an alle Systemer an Ënnersystemer nëmme séier gewinnt.

An deene Joeren huet den Austauschsystem op Hi-End Hardware geschafft - ultra-zouverlässeg HP Superdome 9000 Serveren (gebaut op der Pa-Risc), an deem absolut alles duplizéiert gouf: Input / Output Subsystemer, Netzwierk, RAM (tatsächlech gouf et eng RAID-Array vu RAM), Prozessoren (hot-swappable). Et war méiglech all Server Komponent z'änneren ouni d'Maschinn ze stoppen. Mir hunn op dës Geräter vertraut an hunn se quasi versoen-sécher ugesinn. De Betribssystem war en Unix-ähnlechen HP UX System.

Awer zënter ongeféier 2010 ass e Phänomen entstanen genannt Héichfrequenzhandel (HFT), oder Héichfrequenzhandel - einfach gesot, Bourse Roboter. An nëmmen 2,5 Joer ass d'Laascht op eise Serveren 140 Mol eropgaang.

Evolutioun vun der Architektur vum Handel a Clearing System vun der Moskauer Exchange. Deel 1

Et war onméiglech esou eng Laascht mat der aler Architektur an Ausrüstung ze widderstoen. Et war néideg iergendwéi unzepassen.

Den Ufank

Ufroe fir den Austauschsystem kënnen an zwou Zorte opgedeelt ginn:

  • Transaktiounen. Wann Dir wëllt Dollar, Aktien oder soss eppes kafen, schéckt Dir eng Transaktioun an den Handelssystem a kritt eng Äntwert iwwer Erfolleg.
  • Informatiounen Demanden. Wann Dir den aktuelle Präis gewuer wëllt, kuckt d'Bestellungsbuch oder Indizes, schéckt dann Informatiounsufroen.

Evolutioun vun der Architektur vum Handel a Clearing System vun der Moskauer Exchange. Deel 1

Schematesch kann de Kär vum System an dräi Niveauen opgedeelt ginn:

  • De Clientniveau, op deem Broker a Cliente schaffen. Si interagéieren all mat Zougangsserveren.
  • Gateway-Server sinn Cache-Server déi lokal all Informatiounsufroe veraarbechten. Wëllt Dir wësse wéi en Präis Sberbank Aktien am Moment handelen? D'Ufro geet un den Zougangsserver.
  • Awer wann Dir wëllt Aktien kafen, da geet d'Ufro un den zentrale Server (Trade Engine). Et gëtt een esou Server fir all Typ vu Maart, si spillen eng vital Roll, et ass fir si datt mir dëse System erstallt hunn.

De Kär vum Handelssystem ass eng clever In-Memory Datebank, an där all Transaktiounen Austauschtransaktiounen sinn. D'Basis gouf am C geschriwwen, déi eenzeg extern Ofhängegkeete waren d'libc Bibliothéik an et gouf guer keng dynamesch Erënnerungsallokatioun. Fir d'Veraarbechtungszäit ze reduzéieren, fänkt de System mat engem statesche Set vun Arrays a mat statesche Datenverlagerung un: als éischt ginn all Daten fir den aktuellen Dag an d'Erënnerung gelueden, a kee weideren Diskaccess gëtt duerchgefouert, all Aarbecht gëtt nëmmen an der Erënnerung duerchgefouert. Wann de System ufänkt, sinn all Referenzdaten scho zortéiert, sou datt d'Sich ganz effizient funktionnéiert a wéineg Zäit an der Runtime hëlt. All Dëscher gi mat opdréngleche Lëschten a Beem fir dynamesch Datestrukturen gemaach, sou datt se keng Erënnerungsallokatioun beim Runtime erfuerderen.

Loosst eis kuerz iwwer d'Geschicht vun der Entwécklung vun eisem Handels- a Clearingsystem goen.
Déi éischt Versioun vun der Handels- a Clearing-Systemarchitektur gouf op der sougenannter Unix Interaktioun gebaut: gedeelt Erënnerung, Semaphoren a Schlaangen goufen benotzt, an all Prozess bestoung aus engem eenzege Fuedem. Dës Approche war an de fréien 1990er verbreet.

Déi éischt Versioun vum System enthält zwee Niveaue vu Gateway an en zentrale Server vum Handelssystem. De Workflow war esou:

  • De Client schéckt eng Ufro, déi de Gateway erreecht. Et kontrolléiert d'Validitéit vum Format (awer net d'Donnéeën selwer) a refuséiert falsch Transaktiounen.
  • Wann eng Informatiounsufro geschéckt gouf, gëtt se lokal ausgefouert; wa mir iwwer eng Transaktioun schwätzen, da gëtt se op den zentrale Server ëmgeleet.
  • Den Handelsmotor veraarbecht dann d'Transaktioun, ännert lokal Erënnerung a schéckt eng Äntwert op d'Transaktioun an d'Transaktioun selwer fir d'Replikatioun mat engem separaten Replikatiounsmotor.
  • De Gateway kritt d'Äntwert vum zentrale Node a schéckt se un de Client weider.
  • No enger Zäit kritt de Gateway d'Transaktioun duerch de Replikatiounsmechanismus, an dës Kéier féiert se lokal aus, ännert seng Datestrukturen sou datt déi nächst Informatiounsufroen déi lescht Donnéeën weisen.

Tatsächlech beschreift et e Replikatiounsmodell, an deem de Gateway d'Aktiounen, déi am Handelssystem gemaach goufen, komplett replizéiert huet. En getrennten Replikatiounskanal huet gesuergt datt Transaktiounen an der selwechter Uerdnung iwwer multiple Zougangsknoten ausgefouert goufen.

Zënter datt de Code Single-threaded war, gouf e klassesche Schema mat Prozessgabel benotzt fir vill Clienten ze déngen. Wéi och ëmmer, et war ganz deier fir d'ganz Datebank ze gabel, sou datt liicht Serviceprozesser benotzt goufen déi Pakete vun TCP Sessiounen gesammelt hunn an se an eng Schlaang transferéiert hunn (SystemV Message Queue). Gateway an Trade Engine hunn nëmme mat dëser Schlaang geschafft, Transaktioune vun do aus fir d'Ausféierung geholl. Et war net méi méiglech eng Äntwert drop ze schécken, well et net kloer war, wéi ee Serviceprozess et soll liesen. Also hu mir op en Trick zréckgezunn: all forked Prozess huet eng Äntwertschlaang fir sech selwer erstallt, a wann eng Ufro an déi erakommen Schlaang koum, gouf direkt e Tag fir d'Äntwertschlaang derbäigesat.

Konstant grouss Quantitéiten un Daten aus Schlaang an Schlaang kopéieren huet Probleemer erstallt, besonnesch typesch fir Informatiounsufroen. Dofir hu mir en aneren Trick benotzt: Nieft der Äntwertschlaang huet all Prozess och Shared Memory erstallt (SystemV Shared Memory). D'Packagen selwer goufen dran gesat, an nëmmen e Tag gouf an der Schlaang gespäichert, sou datt een den originelle Package kann fannen. Dëst huet gehollef Daten am Prozessor Cache ze späicheren.

SystemV IPC enthält Utilities fir den Zoustand vu Schlaangen, Erënnerung a Semaphoren Objeten ze gesinn. Mir hunn dëst aktiv benotzt fir ze verstoen wat am System an engem bestëmmte Moment geschitt ass, wou Päck accumuléiert sinn, wat blockéiert gouf, etc.

Éischt Moderniséierungen

Als éischt hu mir de Single-Prozes Gateway lassgelooss. Säi bedeitende Nodeel war datt et entweder eng Replikatiounstransaktioun oder eng Informatiounsufro vun engem Client ka handhaben. A wéi d'Belaaschtung eropgeet, wäert de Gateway méi laang daueren fir Ufroen ze veraarbechten a wäert de Replikatiounsfloss net fäeg sinn. Zousätzlech, wann de Client eng Transaktioun geschéckt huet, da musst Dir just seng Validitéit kontrolléieren an et weider weiderginn. Dofir hu mir den eenzege Gateway-Prozess mat multiple Komponenten ersat, déi parallel kënne lafen: Multi-threaded Informatioun an Transaktiounsprozesser déi onofhängeg vuneneen op engem gemeinsame Gedächtnisgebitt mat RW Sperrung lafen. A gläichzäiteg hu mir Verschécken a Replikatiounsprozesser agefouert.

Impakt vun héich Frequenz Trading

Déi uewe Versioun vun der Architektur existéiert bis 2010. Mëttlerweil ware mir net méi zefridden mat der Leeschtung vun HP Superdome Serveren. Zousätzlech war d'PA-RISC Architektur quasi dout; de Verkeefer huet keng bedeitend Updates ugebueden. Als Resultat hu mir ugefaang vun HP UX / PA RISC op Linux / x86 ze plënneren. Den Iwwergank huet ugefaang mat der Adaptatioun vun Zougangsserveren.

Firwat hu mer d'Architektur nees missen änneren? D'Tatsaach ass datt den Héichfrequenzhandel de Lastprofil um Systemkär wesentlech geännert huet.

Loosst eis soen datt mir eng kleng Transaktioun hunn, déi e wesentleche Präisännerung verursaacht huet - een huet eng hallef Milliard Dollar kaaft. No e puer Millisekonnen bemierken all Maartparticipanten dëst a fänken un eng Korrektur ze maachen. Natierlech stinn Ufroen an enger riseger Schlaang, déi de System laang dauert fir ze läschen.

Evolutioun vun der Architektur vum Handel a Clearing System vun der Moskauer Exchange. Deel 1

Bei dësem 50 ms Intervall ass d'Duerchschnëttsgeschwindegkeet ongeféier 16 Tausend Transaktiounen pro Sekonn. Wa mir d'Fënster op 20 ms reduzéieren, kréie mir eng duerchschnëttlech Geschwindegkeet vun 90 Tausend Transaktiounen pro Sekonn, mat 200 Tausend Transaktiounen am Peak. An anere Wierder, d'Laascht ass net konstant, mat plötzlechen Burst. An d'Schlaang vun Demanden muss ëmmer séier veraarbecht ginn.

Mee firwat ass et iwwerhaapt eng Schlaang? Also, an eisem Beispill, hu vill Benotzer d'Präisännerung gemierkt an Transaktiounen deementspriechend geschéckt. Si kommen op Gateway, et serialiséiert se, setzt eng gewëssen Uerdnung a schéckt se an d'Netz. Router shuffle d'Päckchen a schécken se weider. Wien säi Pak als éischt ukomm ass, dës Transaktioun "gewonnen". Als Resultat hunn d'Austauschclienten ugefaang ze bemierken datt wann déiselwecht Transaktioun vu verschiddene Gateways geschéckt gouf, da sinn d'Chancen fir seng séier Veraarbechtung eropgaang. Geschwënn hunn Austauschroboter ugefaang Gateway mat Ufroen ze bombardéieren, an eng Lawine vun Transaktiounen ass entstanen.

Evolutioun vun der Architektur vum Handel a Clearing System vun der Moskauer Exchange. Deel 1

Eng nei Ronn vun Evolutioun

No extensiv Testen a Fuerschung hu mir op den Echtzäitbetribssystemkerne gewiesselt. Fir dëst hu mir RedHat Enterprise MRG Linux gewielt, wou MRG steet fir Messagerie Echtzäit Gitter. De Virdeel vun Echtzäit Patches ass datt se de System fir déi séierst méiglech Ausféierung optimiséieren: all Prozesser sinn an enger FIFO Schlaang opgestallt, Käre kënnen isoléiert ginn, keng Ausstouss, all Transaktioune ginn a strikt Sequenz veraarbecht.

Evolutioun vun der Architektur vum Handel a Clearing System vun der Moskauer Exchange. Deel 1
Rout - schafft mat enger Schlaang an engem normale Kärel, gréng - schafft an engem Echtzäitkär.

Awer niddereg latency op normale Serveren z'erreechen ass net sou einfach:

  • De SMI Modus, deen an der x86 Architektur d'Basis ass fir mat wichtegen Peripherieger ze schaffen, stéiert immens. D'Veraarbechtung vun all Zorte vu Hardware-Evenementer a Gestioun vu Komponenten an Apparater gëtt vun der Firmware am sougenannten transparenten SMI Modus gemaach, an deem de Betribssystem guer net gesäit wat d'Firmware mécht. Als Regel, bidden all gréisser Ubidder speziell Extensiounen fir Firmware Serveren, déi d'Quantitéit vun der SMI Veraarbechtung reduzéieren.
  • Et soll keng dynamesch Kontroll vun der Prozessor Frequenz ginn, dëst féiert zu zousätzlech Auswee.
  • Wann d'Dateiesystem Log gespullt gëtt, passéiere verschidde Prozesser am Kärel, déi onberechenbar Verzögerungen verursaachen.
  • Dir musst op Saache wéi CPU Affinitéit, Interrupt Affinity, NUMA oppassen.

Ech muss soen datt d'Thema fir Linux Hardware a Kernel opzestellen fir Echtzäitveraarbechtung en separaten Artikel verdéngt. Mir hunn vill Zäit verbruecht fir ze experimentéieren a recherchéieren ier mir e gutt Resultat erreecht hunn.

Wann Dir vun PA-RISC Serveren op x86 plënnert, hu mir praktesch net de Systemcode vill geännert, mir hunn et just ugepasst an nei konfiguréiert. Zur selwechter Zäit hu mir e puer Bugs fixéiert. Zum Beispill, d'Konsequenze vun der Tatsaach, datt PA RISC e Big endian System war, an x86 war e Little endian System, séier Surface: Zum Beispill, Daten goufen falsch gelies. D'trickier Käfer war dass PA RISC benotzt konsequent konsequent (Sequentiell konsequent) Gedächtniszougang, wärend x86 Liesoperatioune kann nei bestellen, sou datt de Code deen absolut valabel war op enger Plattform op enger anerer gebrach ass.

Nom Wiessel op x86 ass d'Performance bal dräimol eropgaang, déi duerchschnëttlech Transaktiounsveraarbechtungszäit ass op 60 μs erofgaang.

Loosst eis elo méi no kucken wéi eng Schlësselännerungen an der Systemarchitektur gemaach goufen.

Hot Reserve Epos

Wann Dir op Commodity Server wiesselt, ware mir bewosst datt se manner zouverlässeg waren. Dofir, bei der Schafung vun enger neier Architektur, hu mir a priori d'Méiglechkeet vum Ausfall vun engem oder méi Wirbelen ugeholl. Dofir war e waarme Standby-System gebraucht, dee ganz séier op Backupmaschinne ka wiesselen.

Zousätzlech goufen et aner Ufuerderungen:

  • Ënner kengen Ëmstänn sollt Dir veraarbecht Transaktiounen verléieren.
  • De System muss absolut transparent fir eis Infrastruktur sinn.
  • D'Clientë sollen net erofgefall Verbindungen gesinn.
  • Reservatioune sollten keng bedeitend Verspéidung aféieren, well dëst e kritesche Faktor fir den Austausch ass.

Wann Dir e waarme Standby-System erstellt, hu mir net sou Szenarie wéi Duebelfehler berücksichtegt (zum Beispill, d'Netzwierk op engem Server huet opgehalen ze schaffen an den Haaptserver ass gefruer); huet d'Méiglechkeet vu Feeler an der Software net berücksichtegt well se während dem Test identifizéiert ginn; an huet déi falsch Operatioun vun der Hardware net berücksichtegt.

Als Resultat si mir op de folgende Schema komm:

Evolutioun vun der Architektur vum Handel a Clearing System vun der Moskauer Exchange. Deel 1

  • Den Haaptserver interagéiert direkt mat de Gateway Serveren.
  • All Transaktiounen, déi um Haaptserver kritt goufen, goufen direkt op de Backup-Server iwwer e separaten Kanal replizéiert. Den Arbitter (Gouverneur) koordinéiert d'Schaltung, wann et Problemer huet.

    Evolutioun vun der Architektur vum Handel a Clearing System vun der Moskauer Exchange. Deel 1

  • Den Haaptserver huet all Transaktioun veraarbecht an op Bestätegung vum Backupserver gewaart. Fir d'Latenz op e Minimum ze halen, hu mir vermeit datt d'Transaktioun op de Backupserver fäerdeg ass. Zënter der Zäit déi et fir eng Transaktioun gedauert huet fir iwwer d'Netz ze reesen war vergläichbar mat der Ausféierungszäit, gouf keng zousätzlech latency bäigefüügt.
  • Mir konnten nëmmen den Veraarbechtungsstatus vun den Haapt- a Backup-Server fir déi viregt Transaktioun kontrolléieren, an den Veraarbechtungsstatus vun der aktueller Transaktioun war onbekannt. Well mir nach ëmmer Single-threaded Prozesser benotzt hunn, waart op eng Äntwert vum Backup hätt de ganze Veraarbechtungsfloss verlangsamt, also hu mir e raisonnabele Kompromiss gemaach: mir hunn d'Resultat vun der viregter Transaktioun gepréift.

Evolutioun vun der Architektur vum Handel a Clearing System vun der Moskauer Exchange. Deel 1

De Schema huet wéi follegt geschafft.

Loosst eis soen datt den Haaptserver ophält ze reagéieren, awer d'Gateways kommunizéieren weider. En Timeout geschitt um Backup Server, et kontaktéiert de Gouverneur, deen him d'Roll vum Haaptserver zougewisen huet, an all Gateways wiesselen op den neien Haaptserver.

Wann den Haaptserver online zréckkënnt, féiert et och en internen Timeout aus, well et fir eng gewëssen Zäit keng Uruff un de Server vum Gateway gouf. Da wendt hien sech och un de Gouverneur, an hien schléisst hien aus dem Schema aus. Als Resultat funktionnéiert den Austausch mat engem Server bis zum Enn vun der Handelsperiod. Zënter datt d'Wahrscheinlechkeet vun engem Serverfehler zimlech niddereg ass, gouf dëse Schema als ganz akzeptabel ugesinn; et huet keng komplex Logik a war einfach ze testen.

Fir weidergeleet gëtt.

Source: will.com

Setzt e Commentaire