Dëst ass eng Fortsetzung vun enger laanger Geschicht iwwer eise thorny Wee fir e mächtege, héichlaaschte System ze kreéieren deen d'Operatioun vum Exchange garantéiert. Den éischten Deel ass hei:
Mysteriéis Feeler
No villen Tester gouf den aktualiséierten Handels- a Clearing-System a Betrib geholl, a mir hunn e Feeler begéint, iwwer dee mir eng Detektiv-mystesch Geschicht schreiwen kënnen.
Kuerz nom Start op den Haaptserver gouf eng vun den Transaktioune mat engem Feeler veraarbecht. Wéi och ëmmer, alles war gutt um Backupserver. Et huet sech erausgestallt, datt eng einfach mathematesch Operatioun vun der Berechnung vum Exponent um Haaptserver en negativt Resultat vum realen Argument huet! Mir hunn eis Fuerschung weidergefouert, an am SSE2 Register hu mir en Ënnerscheed an engem Bit fonnt, dee verantwortlech ass fir d'Ronnung wann Dir mat Floating Point Zuelen schafft.
Mir hunn en einfachen Test Utility geschriwwen fir den Exponent mat der Ronn Bit Set ze berechnen. Et huet sech erausgestallt datt an der Versioun vu RedHat Linux, déi mir benotzt hunn, e Feeler bei der Aarbecht mat der mathematescher Funktioun war, wann de schlechte Bëss agefouert gouf. Mir hunn dëst RedHat gemellt, no enger Zäit krute mir e Patch vun hinnen an hunn se erausgerappt. De Feeler ass net méi opgetrueden, awer et war net kloer, wou dee Bit iwwerhaapt hierkënnt? D'Funktioun war dofir verantwortlech fesetround aus der Sprooch C. Mir hunn eise Code virsiichteg analyséiert op der Sich no dem vermeintleche Feeler: Mir hunn all méiglech Situatiounen iwwerpréift; op all Funktiounen gekuckten déi Ronn benotzt; probéiert eng gescheitert Sëtzung ze reproduzéieren; benotzt verschidde Compilere mat verschiddenen Optiounen; Statesch an dynamesch Analyse goufen benotzt.
D'Ursaach vum Feeler konnt net fonnt ginn.
Duerno hunn se ugefaang d'Hardware ze kontrolléieren: si hunn d'Laaschtprüfung vun de Prozessoren duerchgefouert; kontrolléiert de RAM; Mir hunn souguer Tester gemaach fir de ganz onwahrscheinlechen Szenario vun engem Multi-Bit Feeler an enger Zell. Zu näischt.
Um Enn hu mir eis op eng Theorie aus der Welt vun der Héich-Energiephysik néiergelooss: e puer Héich-Energie-Partikel ass an eisen Rechenzentrum geflunn, d'Mauer vum Fall duerchgebrach, de Prozessor geschloen an d'Ausléiserschlëssel veruersaacht an deem ganzen Deel ze halen. Dës absurd Theorie gouf den "Neutrino" genannt. Wann Dir wäit vun der Partikelphysik sidd: Neutrinoen interagéieren bal net mat der Äussewelt, a si sécher net fäeg d'Operatioun vum Prozessor ze beaflossen.
Well et net méiglech war d'Ursaach vum Echec ze fannen, gouf de "beleidegen" Server aus der Operatioun geläscht just am Fall.
No enger Zäit hu mir ugefaang de waarme Backup-System ze verbesseren: mir hunn de sougenannte "waarm Reserven" (waarm) - asynchrone Repliken agefouert. Si kruten e Stroum vun Transaktiounen, déi a verschiddene Rechenzentren lokaliséiert kënne ginn, awer Warms hunn net aktiv mat anere Server interagéiert.
Firwat gouf dat gemaach? Wann de Backup-Server klappt, da gëtt waarm mam Haaptserver den neie Backup. Dat ass, no engem Echec bleift de System net mat engem Haaptserver bis zum Enn vun der Handelssitzung.
A wann déi nei Versioun vum System getest an a Betrib geholl gouf, ass de Roundbitfehler erëm geschitt. Ausserdeem, mat der Erhéijung vun der Zuel vu waarme Serveren, huet de Feeler méi dacks ugefaang. Gläichzäiteg hat de Verkeefer näischt ze weisen, well et keng konkret Beweiser gouf.
Wärend der nächster Analyse vun der Situatioun ass eng Theorie entstanen datt de Problem mam OS verbonne ka sinn. Mir hunn en einfache Programm geschriwwen, deen eng Funktioun an enger endloser Loop nennt fesetround, erënnert un den aktuellen Zoustand a kontrolléiert et duerch Schlof, an dëst gëtt a ville konkurréiere thread gemaach. Nodeems mir d'Parameteren fir de Schlof an d'Zuel vun den Threads ausgewielt hunn, hu mir ugefaang de Bitfehler konsequent no ongeféier 5 Minutte vum Utility ze reproduzéieren. Wéi och ëmmer, Red Hat Support konnt et net reproduzéieren. Testen vun eisen anere Serveren huet gewisen datt nëmmen déi mat bestëmmte Prozessoren ufälleg sinn fir de Feeler. Zur selwechter Zäit huet de Wiessel op en neie Kernel de Problem geléist. Um Enn hu mir einfach den OS ersat, an déi richteg Ursaach vum Käfer blouf onkloer.
An op eemol gouf d'lescht Joer en Artikel op Habré publizéiert "" D'Situatioun, déi dra beschriwwe gëtt, war ganz ähnlech wéi eis, awer den Auteur huet d'Enquête weider geholl an eng Theorie virgestallt datt de Feeler am Mikrocode war. A wann Linux Kernels aktualiséiert ginn, aktualiséieren d'Fabrikanten och de Mikrocode.
Weider Entwécklung vum System
Och wa mir de Feeler lassgelooss hunn, huet dës Geschicht eis gezwongen d'Systemarchitektur ze iwwerdenken. Iwwerhaapt ware mir net vun der Widderhuelung vu sou Bugs geschützt.
Déi folgend Prinzipien hunn d'Basis fir déi nächst Verbesserunge vum Reservatiounssystem geformt:
- Dir kënnt kee Vertrauen. Server funktionéiere vläicht net richteg.
- Majoritéit Reservatioun.
- Konsens suergen. Als logesch Zousaz zu Majoritéit Reservatioun.
- Duebel Feeler si méiglech.
- Vitalitéit. Den neie waarme Standby-Schema sollt net méi schlëmm sinn wéi dee virdrun. Den Handel soll onënnerbrach weidergoen bis de leschte Server.
- Liicht Erhéijung vun latency. All Downtime bréngt enorm finanziell Verloschter mat.
- Minimal Netzwierkinteraktioun fir latency sou niddreg wéi méiglech ze halen.
- Wielt en neie Master Server a Sekonnen.
Keen vun de Léisungen, déi um Maart verfügbar sinn, passen eis, an de Raft-Protokoll war nach a senger Kandheet, also hu mir eis eege Léisung erstallt.
Vernetzung
Zousätzlech zum Reservatiounssystem hu mir ugefaang d'Netzwierkinteraktioun ze moderniséieren. Den I/O Subsystem bestoung aus ville Prozesser, déi de schlëmmsten Impakt op Jitter a Latenz haten. Mat Honnerte vu Prozesser déi TCP Verbindunge behandelen, ware mir gezwongen dauernd tëscht hinnen ze wiesselen, an op enger Mikrosekonne Skala ass dëst eng zimlech Zäitopwendeg Operatioun. Awer de schlëmmste Deel ass datt wann e Prozess e Paket fir d'Veraarbechtung kritt huet, huet et an eng SystemV Schlaang geschéckt an duerno op en Event vun enger anerer SystemV Schlaang gewaart. Wéi och ëmmer, wann et eng grouss Zuel vu Wirbelen ass, representéieren d'Arrivée vun engem neien TCP-Paket an engem Prozess an d'Empfang vun Daten an der Schlaang an engem aneren zwee konkurréiere Eventer fir den OS. An dësem Fall, wann et keng physesch Prozessoren fir béid Aufgaben verfügbar sinn, gëtt een veraarbecht, an deen zweeten an enger Waardeschlaang gesat. Et ass onméiglech d'Konsequenze virauszesoen.
An esou Situatiounen kann dynamesch Prozess Prioritéit Kontroll benotzt ginn, mä dëst wäert de Gebrauch vun Ressource-intensiv System Appellen verlaangen. Als Resultat hu mir op ee Fuedem gewiesselt mat der klassescher Epoll, dëst huet d'Geschwindegkeet staark erhéicht an d'Transaktiounsveraarbechtungszäit reduzéiert. Mir hunn och getrennten Netzwierkkommunikatiounsprozesser a Kommunikatioun duerch SystemV lassgelooss, d'Zuel vun de Systemappellen wesentlech reduzéiert an ugefaang d'Prioritéite vun den Operatiounen ze kontrolléieren. Eleng am I/O Subsystem war et méiglech ongeféier 8-17 Mikrosekonnen ze spueren, jee no Szenario. Dëst Single-threaded Schema gouf zënterhier onverännert benotzt; een Epoll thread mat enger Marge ass genuch fir all Verbindungen ze servéieren.
Transaktioun Veraarbechtung
Déi wuessend Laascht op eisem System erfuerdert bal all seng Komponenten Upgrade. Awer leider huet d'Stagnatioun am Wuesstum vun de Prozessoruhrgeschwindegkeet an de leschte Joeren et net méi méiglech gemaach fir Prozesser direkt ze skaléieren. Dofir hu mir décidéiert den Engine-Prozess an dräi Niveauen opzedeelen, mat deem beschäftegtste vun hinnen de Risikokontrollsystem ass, deen d'Disponibilitéit vu Fongen op Konten evaluéiert an d'Transaktioune selwer erstellt. Awer Sue kënnen a verschiddene Währungen sinn, an et war néideg fir erauszefannen, op wéi eng Basis d'Veraarbechtung vun Ufroe soll ënnerdeelt ginn.
Déi logesch Léisung ass et no Währung ze deelen: een Server handelt an Dollar, een aneren an Pounds, an en Drëttel an Euro. Awer wann, mat sou engem Schema, zwou Transaktioune geschéckt gi fir verschidde Währungen ze kafen, da wäert de Problem vun der Portemonnaie Desynchroniséierung entstoen. Awer d'Synchroniséierung ass schwéier an deier. Dofir wier et richteg, getrennt vu Portemonnaien a getrennt vun Instrumenter ze schneiden. Iwwregens, déi meescht westlech Austausch hunn net d'Aufgab Risiken esou akut wéi mir ze kontrolléieren, also meeschtens ass dat offline gemaach. Mir hu missen online Verifizéierung implementéieren.
Loosst eis mat engem Beispill erklären. En Händler wëll $ 30 kafen, an d'Ufro geet op d'Transaktiounsvalidatioun: mir kontrolléieren ob dësen Händler zu dësem Handelsmodus erlaabt ass an ob hien déi néideg Rechter huet. Wann alles an der Rei ass, geet d'Ufro un de Risikoverifizéierungssystem, d.h. fir d'Suffizienz vu Fongen ze kontrolléieren fir eng Transaktioun ofzeschléissen. Et gëtt eng Notiz datt de erfuerderleche Betrag de Moment gespaart ass. D'Ufro gëtt dann un den Handelssystem weidergeleet, deen d'Transaktioun approuvéiert oder net approuvéiert. Loosst eis soen datt d'Transaktioun guttgeheescht ass - da markéiert de Risikoverifizéierungssystem datt d'Suen opgehuewe sinn, an d'Rubelen ginn an Dollar.
Am Allgemengen, enthält de Risiko Iwwerpréiwung System komplex Algorithmen a mécht eng grouss Quantitéit vun ganz Ressource-intensiv Berechnungen, a kontrolléiert net einfach de "Konto Gläichgewiicht", wéi et op den éischte Bléck schéngen kéint.
Wéi mir ugefaang hunn de Engine-Prozess an Niveauen opzedeelen, hu mir e Problem begéint: de Code, deen zu där Zäit verfügbar war, huet aktiv déiselwecht Array vun Daten an de Validatiouns- a Verifizéierungsstadien benotzt, wat d'ganz Codebasis erfuerdert. Als Resultat hu mir eng Technik fir d'Veraarbechtung vun Instruktioune vu modernen Prozessoren geléint: jidderee vun hinnen ass a kleng Etappen opgedeelt a verschidde Aktiounen ginn parallel an engem Zyklus gemaach.
No enger klenger Adaptatioun vum Code hu mir eng Pipeline fir parallel Transaktiounsveraarbechtung erstallt, an där d'Transaktioun an 4 Etappe vun der Pipeline opgedeelt gouf: Netzwierkinteraktioun, Validatioun, Ausféierung a Verëffentlechung vum Resultat
Loosst eis e Beispill kucken. Mir hunn zwee Veraarbechtung Systemer, Serien a parallel. Déi éischt Transaktioun kënnt a gëtt fir Validatioun a béid Systemer geschéckt. Déi zweet Transaktioun kënnt direkt: an engem parallele System gëtt se direkt op d'Aarbecht geholl, an an engem sequenzielle System gëtt et an enger Schlaang gesat fir op déi éischt Transaktioun ze waarden fir duerch déi aktuell Veraarbechtungsstadium ze goen. Dat ass, den Haaptvirdeel vun der Pipelineveraarbechtung ass datt mir d'Transaktiounsschlaang méi séier veraarbecht.
Dëst ass wéi mir mam ASTS + System entstane sinn.
Richteg, och net alles ass sou glat mat Fërderer. Loosst eis soen datt mir eng Transaktioun hunn déi Datenarrays an enger Nopeschtransaktioun beaflosst; Dëst ass eng typesch Situatioun fir en Austausch. Sou eng Transaktioun kann net an enger Pipeline ausgefouert ginn, well et anerer beaflosse kann. Dës Situatioun gëtt Daten Gefor genannt, an esou Transaktioune ginn einfach getrennt veraarbecht: wann déi "schnell" Transaktiounen an der Schlaang auslafen, stoppt d'Pipeline, de System veraarbecht déi "lues" Transaktioun, an dann fänkt d'Pipeline erëm un. Glécklecherweis ass den Undeel vun esou Transaktiounen am Gesamtflow ganz kleng, sou datt d'Pipeline sou selten stoppt datt et d'Gesamtleeschtung net beaflosst.
Dunn hu mir ugefaang de Problem vun der Synchroniséierung vun dräi Threads vun der Ausféierung ze léisen. D'Resultat war e System baséiert op engem Ringbuffer mat fixen Gréisst Zellen. An dësem System ass alles ënnerleien der Veraarbechtungsgeschwindegkeet; Daten ginn net kopéiert.
- All erakommen Netzwierkpakete ginn an d'Allokatiounsstadium.
- Mir setzen se an eng Array a markéieren se als verfügbar fir d'Bühn #1.
- Déi zweet Transaktioun ass ukomm, et ass erëm verfügbar fir d'Etapp 1.
- Den éischte Veraarbechtungs thread gesäit déi verfügbar Transaktiounen, veraarbecht se a bewegt se op déi nächst Stuf vum zweete Veraarbechtungs thread.
- Et veraarbecht dann déi éischt Transaktioun a markéiert déi entspriechend Zell
deleted- et ass elo fir nei Benotzung verfügbar.
Déi ganz Schlaang gëtt op dës Manéier veraarbecht.
D'Veraarbechtung vun all Etapp dauert Eenheeten oder Zénger vu Mikrosekonnen. A wa mir Standard OS Synchroniséierungsschemaen benotzen, da wäerte mir méi Zäit op der Synchroniséierung selwer verléieren. Dofir hu mir ugefaang Spinlock ze benotzen. Wéi och ëmmer, dëst ass ganz schlecht Form an engem Echtzäitsystem, a RedHat empfeelt strikt net dëst ze maachen, sou datt mir e Spinlock fir 100 ms gëllen, a schalten dann op Semaphore Modus fir d'Méiglechkeet vun engem Deadlock ze eliminéieren.
Als Resultat hu mir eng Leeschtung vun ongeféier 8 Milliounen Transaktiounen pro Sekonn erreecht. A wuertwiertlech zwee Méint méi spéit an iwwer LMAX Disruptor hu mir eng Beschreiwung vun engem Circuit mat der selwechter Funktionalitéit gesinn.
Elo kéint et e puer Fuedem vun Ausféierung an enger Etapp ginn. All Transaktioune goufen een nom aneren veraarbecht, an der Uerdnung déi se kritt hunn. Als Resultat ass d'Peakleistung vun 18 Tausend op 50 Tausend Transaktiounen pro Sekonn eropgaang.
Exchange Risiko Management System
Et gëtt keng Limite fir Perfektioun, a geschwënn hu mir d'Moderniséierung erëm ugefaang: Am Kader vun ASTS+ hu mir ugefaang Risikomanagement a Siidlungsoperatiounssystemer an autonom Komponenten ze plënneren. Mir hunn eng flexibel modern Architektur an en neien hierarchesche Risikomodell entwéckelt, a probéiert d'Klass ze benotzen wou et méiglech ass fixed_point anstatt double.
Awer e Problem ass direkt entstanen: wéi all d'Geschäftslogik ze synchroniséieren, déi fir vill Jore geschafft huet an et an den neie System transferéiert? Als Resultat huet déi éischt Versioun vum Prototyp vum neie System missen opginn. Déi zweet Versioun, déi am Moment an der Produktioun schafft, baséiert op deemselwechte Code, deen souwuel am Handel wéi och am Risiko Deel funktionnéiert. Wärend der Entwécklung war déi schwéierst Saach ze maachen git Merge tëscht zwou Versiounen. Eise Kolleg Evgeniy Mazurenok huet dës Operatioun all Woch gemaach an all Kéier huet hien eng ganz laang Zäit verflucht.
Bei der Auswiel vun engem neie System hu mir direkt de Problem vun der Interaktioun missen léisen. Wann Dir en Datebus auswielt, war et néideg fir stabile Jitter a minimal latency ze garantéieren. D'InfiniBand RDMA Netz war am Beschten dofir gëeegent: déi duerchschnëttlech Veraarbechtungszäit ass 4 Mol manner wéi an 10 G Ethernet Netzwierker. Awer wat eis wierklech faszinéiert huet war den Ënnerscheed an de Prozentilen - 99 an 99,9.
Natierlech huet InfiniBand seng Erausfuerderungen. Als éischt eng aner API - ibverbs anstatt Sockets. Zweetens, et gi bal keng wäit verfügbar Open Source Messagerie Léisungen. Mir hu probéiert eisen eegene Prototyp ze maachen, awer et huet sech ganz schwéier erausgestallt, also hu mir eng kommerziell Léisung gewielt - Confinity Low Latency Messaging (fréier IBM MQ LLM).
Dunn ass d'Aufgab entstane fir de Risikosystem richteg opzedeelen. Wann Dir einfach de Risk Engine ewechhuelt an keen Zwëschennode erstellt, da kënnen Transaktioune vun zwou Quelle gemëscht ginn.
Déi sougenannte Ultra Low Latency-Léisungen hunn e Reorder-Modus: Transaktioune vun zwou Quellen kënnen an der erfuerderter Uerdnung beim Empfang arrangéiert ginn; dëst gëtt mat engem separaten Kanal ëmgesat fir Informatioun iwwer d'Bestellung auszetauschen. Awer mir benotzen dëse Modus nach net: et komplizéiert de ganze Prozess, an an enger Rei vu Léisungen gëtt et guer net ënnerstëtzt. Zousätzlech muss all Transaktioun entspriechend Zäitstempel zougewisen ginn, an an eisem Schema ass dëse Mechanismus ganz schwéier korrekt ëmzesetzen. Dofir hu mir de klassesche Schema mat engem Message Broker benotzt, dat heescht mat engem Dispatcher deen Messagen tëscht dem Risk Engine verdeelt.
Den zweete Problem war mam Client Zougank am Zesummenhang: wann et e puer Risk Gateways gëtt, muss de Client mat jiddereng vun hinnen konnektéieren, an dëst erfuerdert Ännerungen an der Clientschicht. Mir wollten op dëser Etapp vun dësem ewech kommen, sou datt den aktuellen Risk Gateway Design de ganzen Datestroum veraarbecht. Dëst limitéiert immens de maximalen Débit, awer vereinfacht d'Systemintegratioun staark.
Duplikatioun
Eise System soll net een eenzege Punkt vun Echec hunn, dat ass, all Komponente mussen duplizéiert ginn, dorënner de Message Broker. Mir hunn dëse Problem mam CLLM-System geléist: et enthält en RCMS-Cluster, an deem zwee Dispatcher am Master-Sklave-Modus kënne schaffen, a wann een ausfällt, wiesselt de System automatesch op deen aneren.
Schafft mat engem Backup-Datenzentrum
InfiniBand ass fir Operatioun als lokal Netzwierk optimiséiert, dat ass, fir Rack-Mount Ausrüstung ze verbannen, an en InfiniBand Netz kann net tëscht zwee geographesch verdeelt Datenzenter geluecht ginn. Dofir hu mir eng Bréck / Dispatcher ëmgesat, déi mat der Noriichtespäicherung iwwer regelméisseg Ethernet Netzwierker verbënnt an all Transaktiounen op en zweet IB Netz relaiséiert. Wa mir mussen aus engem Rechenzentrum migréieren, kënne mir wielen mat wéi engem Rechenzentrum mir elo schaffen.
Resultater
All déi uewe gouf net op eemol gemaach; et huet e puer Iteratiounen gedauert fir eng nei Architektur z'entwéckelen. Mir hunn de Prototyp an engem Mount erstallt, awer et huet méi wéi zwee Joer gedauert fir en an d'Aarbechtskonditioun ze kréien. Mir hu probéiert de beschte Kompromiss tëscht der Erhéijung vun der Transaktiounsveraarbechtungszäit an der Erhéijung vun der Systemverlässegkeet z'erreechen.
Zënter datt de System staark aktualiséiert gouf, hu mir Daten Erhuelung vun zwou onofhängege Quellen ëmgesat. Wann de Message Store aus irgendege Grënn net korrekt funktionnéiert, kënnt Dir den Transaktiounsprotokoll vun enger zweeter Quell huelen - vum Risk Engine. Dëse Prinzip gëtt am ganze System observéiert.
Ënner anerem konnte mir de Client API erhaalen, sou datt weder Broker nach iergendeen eng bedeitend Neiaarbecht fir déi nei Architektur erfuerderen. Mir hu missen e puer Schnëttplazen änneren, awer et war kee Besoin fir bedeitend Ännerungen am Betribsmodell ze maachen.
Mir hunn déi aktuell Versioun vun eiser Plattform Rebus genannt - als Ofkierzung fir déi zwee merkbarst Innovatiounen an der Architektur, Risk Engine a BUS.
Am Ufank wollte mir nëmmen de Clearing-Deel verdeelen, awer d'Resultat war e rieseg verdeelt System. D'Clientë kënnen elo entweder mam Trade Gateway, dem Clearing Gateway oder béid interagéieren.
Wat mir schlussendlech erreecht hunn:
Reduzéiert Latenzniveau. Mat engem klenge Volumen vun Transaktiounen funktionnéiert de System d'selwecht wéi déi viregt Versioun, awer gläichzäiteg kann e vill méi héich Laascht widderstoen.
Peak Performance ass vun 50 Tausend op 180 Tausend Transaktiounen pro Sekonn eropgaang. Eng weider Erhéijung gëtt behënnert duerch den eenzege Stroum vun der Uerdnungsmatchung.
Et ginn zwou Méiglechkeeten fir weider Verbesserung: Paralleliséierung vum Match an de Wee wéi et mat Gateway funktionnéiert. Elo funktionnéieren all Gateways no engem Replikatiounsschema, deen ënner esou enger Laascht ophält normal ze funktionnéieren.
Schlussendlech kann ech e puer Rotschléi ginn fir déi, déi d'Entreprise Systemer finaliséieren:
- Bereet Iech op dat Schlëmmst zu all Moment. Problemer entstinn ëmmer onerwaart.
- Et ass normalerweis onméiglech fir séier Architektur nei ze maachen. Besonnesch wann Dir maximal Zouverlässegkeet iwwer verschidde Indikatoren muss erreechen. Wat méi Noden, wat méi Ressourcen fir Ënnerstëtzung gebraucht ginn.
- All personaliséiert a propriétaire Léisungen erfuerderen zousätzlech Ressourcen fir Fuerschung, Ënnerstëtzung an Ënnerhalt.
- Setzt net d'Léisung vun Probleemer vun der Systemverlässegkeet an der Erhuelung no Feeler of; huelt se an der initialer Designstadium berücksichtegt.
Source: will.com