Outomatiese Handel Stelsel Argitektuur

Algoritmiese Trading System Architecture Voorheen op hierdie blog ek oor die konseptuele argitektuur van 'n intelligente algoritmiese handel stelsel asook die funksionele en nie-funksionele vereistes van 'n produksie algoritmiese handel stelsel geskryf. Sedertdien het ek ontwerp het 'n stelsel-argitektuur wat ek glo kan voldoen aan diegene argitektoniese vereistes. In hierdie pos sal ek die argitektuur na aanleiding van die riglyne van die ISO / IEC / IEEE 42010 stelsels en sagteware-ingenieurswese argitektuur beskrywing standaard beskryf. Volgens hierdie standaard n argitektuur beskrywing moet: Bevat verskeie gestandaardiseerde argitektoniese sienings (bv in UML) en in stand te hou naspeurbaarheid tussen ontwerp besluite en argitektoniese vereistes sagteware argitektuur definisie Daar is steeds geen konsensus oor wat 'n stelsels argitektuur is. In die konteks van hierdie artikel, is dit gedefinieer as die infrastruktuur waarbinne aansoek komponente wat funksionele vereistes voldoen kan word vermeld, ontplooi, en uitgevoer word. Funksionele vereistes is die verwagte funksies van die stelsel en sy komponente. Nie-funksionele vereistes is maatreëls waardeur die kwaliteit van die stelsel gemeet kan word. 'N Stelsel wat ten volle voldoen aan die funksionele vereistes kan steeds nie na wense as funksionele vereistes ontevrede gelaat. Om te illustreer hierdie konsep beskou die volgende scenario: 'n algoritmiese handel stelsel wat jy nou net gekoop het / gebou maak uitstekende handel besluite te neem, maar is heeltemal in onbruik met die organisasies risikobestuur en rekeningkundige stelsels. Sou hierdie stelsel voldoen aan jou verwagtinge Konseptuele Architecture 'n konseptuele siening beskryf hoë vlak konsepte en meganismes wat bestaan ​​in die stelsel op die hoogste vlak van korrelig. Op hierdie vlak, die algoritmiese handel stelsel volg 'n gebeurtenis gedrewe argitektuur (EDA) oopgebreek oor vier lae, en twee argitektoniese aspekte. Vir elke laag en aspek verwys argitekture en patrone gebruik. Argitektoniese patrone bewys, generiese strukture vir die bereiking van spesifieke vereistes. Argitektoniese aspekte is kruissnydende kommer wat verskeie komponente span. Gebeurtenis gedrewe argitektuur - 'n argitektuur wat produseer, bespeur, verbruik, en reageer op gebeure. Gebeure sluit in reële tyd mark bewegings, komplekse gebeure of tendense, en handel gebeure bv indiening van 'n bevel. Hierdie diagram illustreer die konseptuele argitektuur van die algoritmiese handel stelsel Verwysing architecture 'n analogie te gebruik, 'n verwysing argitektuur is soortgelyk aan die bloudrukke vir 'n lasdraende muur. Dit bloudruk kan weer gebruik word vir verskeie bou-ontwerpe ongeag wat gebou is gebou as dit voldoen aan 'n stel algemeen voorkom vereistes. Net so, 'n verwysing argitektuur definieer 'n sjabloon bevat generiese strukture en meganismes wat gebruik kan word om 'n konkrete sagteware argitektuur wat spesifieke vereistes voldoen te bou. Die argitektuur vir die algoritmiese handel stelsel gebruik 'n ruimte gebaseerde argitektuur (SBA) en 'n model oog kontroleerder (MVC) as verwysings. Goeie praktyke soos die operasionele data stoor (ODS), die uittreksel te transformeer en vrag (ETL) patroon, en 'n datapakhuis (DW) word ook gebruik. Model oog kontroleerder - 'n patroon wat die voorstelling van inligting van die gebruikers interaksie met hulle skei. Ruimte gebaseerde argitektuur - spesifiseer 'n infrastruktuur waar losweg gekoppel verwerking eenhede met mekaar deur middel van 'n gedeelde assosiatiewe geheue genoem ruimte (sien onder). Strukturele View Die strukturele siening van 'n argitektuur toon die komponente en sub-komponente van die algoritmiese handel stelsel. Dit wys ook hoe hierdie komponente is ontplooi op fisiese infrastruktuur. Die UML diagramme in hierdie siening sluit komponent diagramme en ontplooiing diagramme. Hier is 'n gallery van die ontplooiing diagram van die algehele algoritmiese handel stelsel en die verwerking eenhede in die SBA verwysing argitektuur, asook verwante komponent diagramme vir elkeen die lae. Argitektoniese Tactics Volgens die sagteware-ingenieurswese Instituut 'n argitektoniese taktiek is 'n manier te bevredig 'n vereiste gehalte deur die manipulering een of ander aspek van 'n gehalte kenmerk model deur middel van argitektoniese ontwerp besluite te neem. 'N Eenvoudige voorbeeld gebruik word in die algoritmiese handel stelsel argitektuur manipuleer 'n operasionele data stoor (ODS) met 'n deurlopende bevraagteken komponent. Hierdie komponent sal voortdurend analiseer die ODS te identifiseer en te onttrek komplekse gebeure. Die volgende taktiek gebruik word in die argitektuur: die disruptor patroon in die geval en orde toue gedeelde geheue vir die geleentheid en orde toue Deurlopende bevraagteken taal (CQL) op die ODS Data filter met die filter ontwerp patroon op inkomende data Opeenhoping vermyding algoritmes op alle inkomende en uitgaande verbindings Active tou bestuur (AQM) en eksplisiete opeenhoping kennisgewing Commodity rekenaar hulpbronne met kapasiteit vir opgradering (skaalbare) Active ontslag vir al enkele punte van mislukking Indexatie en optimale volharding strukture in die ODS Skeduleer gereelde data rugsteun en skoon-up skrifte vir ODS transaksie geskiedenis op alle databasisse checksums vir alle bestellings op te spoor foute Annoteer gebeure met tyd tempel te verjaar gebeure slaan Bestel validering reëls bv maksimum handel hoeveelhede outomatiese handelaar komponente gebruik 'n in-geheue databasis vir ontleding Twee stadium verifikasie vir gebruikerkoppelvlakke verbinding met die TGT Enkripsie op gebruikerkoppelvlakke en verbindings na die TGT Observer ontwerp patroon vir die MVC om menings te bestuur Bogenoemde lys is net 'n paar ontwerp besluite wat ek geïdentifiseer tydens die ontwerp van die argitektuur. Dit is nie 'n volledige lys van taktiek. As die stelsel word ontwikkel bykomende taktiek moet in diens geneem word oor verskeie vlakke van korrelig om funksionele en nie-funksionele vereistes te voldoen. Hieronder is drie diagramme beskryf die disruptor ontwerp patroon, filter ontwerp patroon, en die voortdurende bevraagtekening komponent. Gedragswetenskappe Sien die lig van 'n argitektuur wys hoe die komponente en lae moet in wisselwerking met mekaar. Dit is sinvol as die skep van scenario's vir die toets van argitektuur ontwerp en vir die begrip van die stelsel van end-tot-end. Hierdie siening bestaan ​​uit volgorde diagramme en aktiwiteite diagramme. Aktiwiteit diagramme toon die algoritmiese handel stelsels interne proses en hoe handelaars is veronderstel om met die algoritmiese handel stelsel word hieronder getoon. Tegnologie en raamwerke Die finale stap in die ontwerp van 'n sagteware-argitektuur is om potensiële tegnologie en raamwerke wat gebruik kan word om die argitektuur te besef identifiseer. As 'n algemene beginsel is dit beter om te hefboom af van bestaande tegnologie, met dien verstande dat hulle voldoende bevredig beide funksionele en nie-funksionele vereistes. 'N Raamwerk is 'n besef verwysing argitektuur bv JBoss is 'n raamwerk wat die JEE verwysing argitektuur besef. Die volgende tegnologie en raamwerke is interessant en moet in ag geneem word wanneer die uitvoering van 'n algoritmiese handel stelsel: CUDA - NVidia het 'n aantal produkte wat 'n hoë werkverrigting rekenaar Finansies modellering ondersteun. 'N Mens kan bereik tot 50x prestasie verbeterings in die bestuur van Monte Carlo simulasies op die GPU in plaas van die CPU. Apache River - River is 'n instrument-kit wat gebruik word om verspreide stelsels te ontwikkel. Dit is gebruik as 'n raamwerk vir die bou van toepassings gebaseer op die SBA patroon Apache Hadoop - in die geval dat deurdringende meld is 'n vereiste, dan is die gebruik van Hadoop bied 'n interessante oplossing vir die groot-data probleem. Hadoop ontplooi kan word in 'n cluster omgewing ondersteun CUDA tegnologie. AlgoTrader - 'n open source algoritmiese handel platform. AlgoTrader kan potensieel ontplooi in die plek van die outomatiese handelaar komponente. FIX Engine - 'n selfstandige toepassing wat die Finansiële Information Exchange (FIX) protokolle insluitend FIX ondersteun, vinnig, en FIXatdl. Terwyl nie 'n tegnologie of 'n raamwerk, moet komponente word gebou met 'n aansoek Programming Interface (API) om interoperabiliteit van die stelsel en sy komponente te verbeter. Ten slotte Die voorgestelde argitektuur is ontwerp om baie generiese vereistes geïdentifiseer vir algoritmiese handel stelsels te bevredig. Oor die algemeen algoritmiese handel stelsels is bemoeilik deur drie faktore wat wissel met elke uitvoering: Afhanklike gebiede op eksterne onderneming en ruil stelsels Uitdaag-funksionele vereistes en veranderende argitektoniese beperkings Die voorgestelde sagteware argitektuur sou dus moet word aangepas op 'n geval-tot-geval grondslag ten einde om spesifieke organisatoriese en regulatoriese vereistes voldoen, asook aan die plaaslike beperkings te oorkom. Die algoritmiese handel stelsel argitektuur moet gesien word as net 'n punt van verwysing vir individue en organisasies wat hul eie algoritmiese handel stelsels te ontwerp. Vir 'n volledige kopie en bronne wat gebruik gaan aflaai 'n afskrif van my verslag. Dankie. TagsThere is eintlik net 3 groot blokke in 'n Algo Trading System. 1. Mark data Handler (bv FAST hanteerder) 2. Strategie Module (bv crossover strategie) 3. Bestel Router (bv FIX router) jy kan Risiko tjeks voeg by óf die strategie module of die Orde Router module of beide. Solank jou data vloei korrek is, moet jy goed om te gaan. Onthou jy die ontwerp van 'n ATS vir minimum latency, en die toevoeging van meer lae of kompleksiteit sal ten koste van latency kom. Minimale ATS argitektuur en as jy die klokkies en fluitjies voeg, sal dit lyk soos die volgende: As jy ook geïnteresseerd in die nitty-gritty van die implementering van die bogenoemde argitektuur, moet jy die volgende dinge in gedagte te hou. Vermy slotte / mutexes. In die geval het jy om dit te gebruik, probeer om hulle te vervang met lockless strukture met behulp van Atomics. Daar is n paar biblioteke beskikbaar vir lockless datastrukture (bv libcds, concurrency kit ens). C-11 ondersteun st :: atoom. en jy moet daarna streef om dit te gebruik as well. Vermy whats gedoen Quickfix. Sy geskryf vir veiligheid / soepelheid / reusab ility as voorwerp (slot) skepping en vernietiging vir elke oproep van enige boodskap aan router gedoen. Sekerlik geen manier om 'n latency sensitiewe kode te skryf. Geen runtime geheuetoekenning. runtime pad moet persoonlike en uitsluiting gratis geheuebestuur gebruik met pre-toegeken geheue swembad. Al die inisialisering kan gedoen word in vervaardigerskampioenskap. Stywe koppeling. Threading model, I / O-model en geheue bestuur moet ontwerp word om saam te werk met mekaar om die beste algehele prestasie te bereik. Dit druis in teen die OOP konsep van los koppeling, maar sy nodig om runtime koste van dinamiese polimorfisme te vermy. Gebruik Templates. In dieselfde trant, sal ek ook voor dat jy kyk na C templatization om buigsaamheid van kode te bereik. OS / Hardware optimalisering Uiteindelik, moet jy kyk om te werk met Linux RT kern en Solarflare netwerkkaart met OpenOnLoad bestuurder vir die bereiking van die minimum latency. jy kan verder kyk na die CPU isoleer en uit te voer jou program op daardie spesifieke kern. En ten slotte die openbare API wat jy nodig sou wees om bloot te stel aan strategie ontwikkelaars. Ek wil graag hierdie aan die minimale stel wat al die kompleksiteit van die betrokke ruil / bestemming sou omsluit wees. klas OrderRouter openbare: virtuele Bool sendNewOrd (OrderInfo) 0 virtuele Bool sendRplOrd (OrderInfo) 0 virtuele Bool sendCxlOrd (OrderInfo) 0 virtualBut dit beteken dat die OrderInfo Klas moet al die besonderhede wat vereis word deur die bestemming / ruil het. In die algemeen, die uitruil vereis dieselfde soort inligting, maar as jy gaan saam en ondersteun meer beurse / bestemmings jy sal vind jouself die toevoeging van meer veranderlikes in hierdie klas. Die volgende is die belangrikste vrae / uitdagings wat jy nodig sou wees om jouself te vra: 1. Multi-proses argitektuur of multi-gestruktureerde argitektuur. of om 'n monolitiese proses bou met verskeie drade, of skryf 'n paar prosesse. Die koste van verskeie proses is boodskap verby latency, terwyl die koste vir verskeie stringe enkele proses is dat enige versuim in die hele stelsel kan bring. 2. Boodskap afsterwe: terwyl jy kan kies uit oorvloed van opsies, jy beperk deur latency oorweging. Vinnigste IPC sou gedeel geheue, maar dan hoe sou jy doen die sinchronisasie spandeer 'n geruime tyd met hierdie twee vrae omdat hulle die boublok waarop jou argitektuur staan ​​sou wees. Edit: FIX en vinnig Met betrekking tot gewilde / standaard protokol, FIX is vir die stuur van bestellings en vinnig vir die mark data. Noudat dit gesê is, die meeste ruil hul eie moedertaal protokol wat is vinniger as op te los, want FIX algemeen geïmplementeer op die top van hul moedertaal protokol. Maar hulle het steeds ondersteun FIX dra by tot spoed van ontplooiing. Aan die ander kant, terwyl bepaal deur die grootste deel van die uitruil aangeneem, vinnig geniet nie so 'n wye aanvaarding. As daar iets is, sal daar net 'n handjievol van ruil aanneming dit so wees. Die meeste van hulle óf stuur oor FIX self (lae latency), of hul eie moedertaal binêre protokol. bv In Indië, NSE, BSE en MCX / MCXSX, al die drie beurse gee jy los protokol bykomend tot inheemse protokol, maar slegs BSE gee jou vinnig vir markdata. En dit is ook die verskuiwing van vinnig om moedertaal met bekendstelling van EOBI. jy kan dieselfde ding ekstrapoleer na ander ruil. 2.8k Views middot View upvotes middot Nie vir Reproduksie Soos Johannes genoem, OMS is die kern van enige verhandelingsplatform en jy moet begin van die ondersoek nie. Jy wil hê om tyd te spandeer om jou handel lewensiklus, gebeure en funksies wat jy wil in te sluit op die OMS en die mense wat jy wil hê dat jou Algo Engine hanteerbaar te bepaal. Metcetera bied 'n oop bron OMS, ek haven039t dit persoonlik gebruik, maar it039s een van die min in die mark. Die volgende ding wat jy moet kyk na is die verskaffing van 'n koppelvlak tot brondata in en druk dit uit. Dit is vir 'n kliënt om toegang stelsel te gooi in die orde besonderhede en Algo enjin om dit te bekom. Baie Sell Side OMS039s gebruik 'n kombinasie van eie programme geskryf in Java / C met behulp los. FIX protokol kan jy realtime kommunikeer oor stelsels in 'n vereenvoudigde amp pre-gedefinieerde boodskap deur die FIX protokol gemeenskap gelê formaat. Gaan na Die FIX protokol Organisasie GT Tuis bladsy vir meer daaroor te lees. Ook kyk na Open Source FIX Engine. 'n open source implementering van die FIX enjin. Volgende kom 'n Mark data koppelvlak tot bron realtime tyd sekuriteit mark inligting, data wat wissel van High / Low / Open / Close na Best bid / Best ask, Total verhandel volume, Laaste prys, Laaste volume, Bid haal, Vra aanhalings ens Die inligting jy soek regtig hang af van die tipe strategie wat jy wil uit te voer. Ek glo Interaktiewe Broker bied 'n real-time data voer via los. Ruil verbinding is langs waar u Algo interpreteer die seine, skep 'n bevel en roetes na 'n ruil of ECN. Die ontwikkeling van dit in die huis kon moeilik wees as jy nodig sou wees om uit te werk Exchange lidmaatskap, sertifiseer jou platform en betaal 'n gereelde ledegeld. 'N goedkoper manier is om 'n makelaar API (soos IB) en roete aan die orde deur dit te gebruik. Historiese data is van wese te as wat jy dalk wil die huidige mark gedrag met sy historiese waardes te vergelyk. Parameters soos normaal verspreiding, VWAP profiele, kan gemiddelde daaglikse volume ens word benodig om besluitneming te beïnvloed. Jy kan dit op die databasis (voorkeur) maar as spoed van die wese dan laai dit op die bediener kas wanneer jy jou program te begin. Sodra jou perifere stelsels ingestel is, kan jy begin met die ontwikkeling van jou algo program die manier waarop jy dit wil hê om te werk. Dit basiese infrastruktuur sal jou toelaat om insette 'n ouer algo orde, lees data mark, reageer op die seine, maar genereer kind bestellings en plaas dit op die uitruil bestelboek en historiese data te besluitneming beïnvloed. Die OMS het die verband tussen die ouer amp kind orde, hul realtime status en updates deur die algo of ruil konneksie platform. Wat jy wil uit te voer binne die Algo is heeltemal aan jou. 1.8k Views middot View upvotes middot Nie vir Reproduksie Martin Krmer. rekenaarwetenskaplike, full-stapel kodeerder, wat 'n goeie idee van die masjien leer Dit lyk baie makliker as wat jy dalk dink as hulle hoofdoel is om antwoorde op seine in die orde van mikrosekondes en nie die optimalisering vir enige soort van ingewikkelde model te bereik. In die praktyk beteken dit dat jy nie iets kan bekostig, behalwe 'n paar baie basiese wiskunde te. So groot handelaars in hierdie gebied werklik geld te maak deur in staat is om 'n micro vinniger as 'n mededinger en nie reageer deur die interpretasie van die data in 'n complicted mode. 2.1k Views middot View upvotes middot Nie vir ReproductionIt nie die geval blyk Moontlike. Maar dit is met ons algoritme handel strategieë Dit nie die geval moontlik lyk. Een algoritmiese stelsel handel met soveel tendens identifikasie, siklus analise, koop / verkoop kant volume vloei, verskeie handel strategieë, dinamiese inskrywing, teiken en stop pryse, en ultra-vinnige sein tegnologie. Maar dit is. Trouens, AlgoTrades algoritmiese handel stelsel platform is die enigste een van sy soort. Nie meer op soek na warm voorrade, sektore, kommoditeite, indekse, of opinies lees mark. Algotrades doen al die soek, tydsberekening en handel vir jou gebruik van ons algoritmiese handel stelsel. AlgoTrades beproefde strategieë kan met die hand, gevolg deur die ontvangs van e-pos en sms-boodskappe, of dit kan 100 hands-free handel, sy aan jou Jy kan op enige tyd draai op / af outomatiese handel, sodat jy altyd in beheer van jou bestemming wees. Outomatiese handel stelsels vir Savvy Beleggers Kopiereg 2016 - ALGOTRADES - outomatiese Algorithmic Trading System CFTC REËL 4.41 - hipotetiese of gesimuleerde prestasieresultate sekere beperkings. Anders as 'n werklike vertoningslys, MOENIE gesimuleerde uitslae verteenwoordig werklike handel. Ook, omdat Die bedrywe HET NIE uitgevoer, kan die resultate is onder-OF-OOR vergoed vir die impak, indien enige, van SEKERE markfaktore, soos 'n gebrek aan likiditeit. Gesimuleerde TRADING programme in die algemeen ook onderhewig aan die feit dat hulle is ontwerp met die voordeel van agterna. GEEN VERTEENWOORDIGING gemaak DAT ENIGE rekening of waarskynlik om voordeel te trek of verliese soortgelyk aan dié wat ACHIEVE. Geen voorstelling gemaak of geïmpliseer dat die gebruik van die algoritmiese handel stelsel inkomste sal genereer of 'n wins te waarborg. Daar is 'n aansienlike risiko van verlies wat verband hou met termynkontrakte handel en handel beursverhandelde fondse. Futures handel en handel beursverhandelde fondse behels 'n aansienlike risiko van verlies en is nie geskik vir almal. Hierdie resultate is gebaseer op gesimuleerde of hipotetiese prestasie resultate wat sekere inherente beperkings het. In teenstelling met die bedrag wat in 'n werklike prestasie rekord resultate, moenie hierdie resultate nie verteenwoordig werklike handel. Ook, omdat hierdie ambagte het nie eintlik uitgevoer, hierdie resultate kan hê onder-of oor-vergoed vir die impak, indien enige, van sekere mark faktore, soos 'n gebrek aan likiditeit. Gesimuleerde of hipotetiese handel programme in die algemeen is ook onderhewig aan die feit dat hulle is ontwerp met die voordeel van agterna. Geen voorstelling gemaak word dat enige rekening sal of waarskynlik winste of verliese soortgelyk aan dié bereik wat gewys. Inligting op hierdie webwerf is opgestel sonder inagneming van enige spesifieke beleggingsdoelwitte beleggers, finansiële situasie en behoeftes en verder beveel intekenaars om nie op te tree op enige inligting sonder om spesifieke advies van hul finansiële adviseurs nie staatmaak op inligting van die webwerf as die primêre basis vir hul beleggingsbesluite en om hul eie risikoprofiel, risikotoleransie, en hul eie stop verliese te oorweeg. - Aangedryf deur omvou WordPress ThemeHow Is 'n algoritmiese Trading System Werk Of jy nou 'n kleinhandel handelaar belê jou spaargeld in die aandelemark of 'n tegniese ontleding deskundige of 'n heining fondsbestuurder, die eerste stap om te begin jou eie algoritmiese handel is om te verstaan ​​hoe dit werk . Algoritmiese Trading vereis die verwydering van 'n menslike handelaar deur 'n masjien, wat sy eie handel besluite kan neem en voer die besluite. Die algoritmiese handel stelsel bestaan ​​uit drie hoofkomponente wat getoon in die diagram hieronder: Market Adapter Exchange of enige mark data verkoper stuur data in hul eie formaat. Jou algoritmiese handel stelsel kan of mag nie verstaan ​​dat taal. Ruil bied jou met 'n API of 'n aansoek program Interface wat jou toelaat om die program en die skep van jou eie adapter wat die formaat van die data kan omskep in die formaat van jou stelsel kan verstaan. Komplekse Event Processing Engine Hierdie deel is die brein van jou strategie. Sodra jy die data het, sou jy nodig het om te werk met dit soos per jou strategie wat behels doen verskeie statistiese berekeninge, vergelykings met historiese data en besluitneming vir orde geslag. Die bevel kragtens tipe orde, is bestel hoeveelheid voorberei in hierdie blok. Bestel Routing System Die bevel word geïnkripteer in die taal wat ruil kan verstaan, weer met behulp van die API's wat deur die uitruil. Daar is twee soorte APIs wat deur die uitruil: moedertaal API en op te los API. Inheemse API is dié wat spesifiek vir 'n bepaalde ruil is. Die FIX (Finansiële Information Exchange) protokol is 'n stel reëls wat gebruik word in die verskillende beurse om die data vloei in markte sekuriteit makliker en doeltreffend te maak. In die geval van 'n oop ekonomie, kan 'n mens bevel ruil of nie-ruil en ORP stuur moet in staat wees om bestellings te hanteer om verskillende bestemmings. Volgende stap As jy 'n kleinhandel handelaar of 'n tegnologie professionele soek om jou eie outomatiese handel lessenaar begin, begin leer algo handel vandag Begin met basiese begrippe soos outomatiese handel argitektuur. mark mikrostruktuur. strategie back testing stelsel en orde bestuurstelsel. Jy kan ook inskryf in EPAT, een van die mees omvattende algoritmiese handel opleidingsprogram in die bedryf. Related Posts: Algorithmic Trading System Architecture Algorithmic outomatiese handel of Algorithmic Trading is in die middel-fase van die handel wêreld vir 'n paar jaar nou. Die persentasie van volumes toegeskryf word aan hierdie vorm van handel is besig om in die afgelope paar jaar. As gevolg hiervan, het dit 'n hoogs mededingende mark wat baie afhanklik van tegnologie geword. Gevolglik het die basiese argitektuur groot veranderinge oor die afgelope dekade ondergaan en gaan voort om dit te doen. Dit is vandag 'n noodsaaklikheid om te herstel van tegnologie om mee te ding in die wêreld van algoritmiese handel, maak dit 'n broeikas vir vooruitgang in rekenaar-en netwerk-tegnologie. Tradisionele argitektuur Enige handel stelsel, konseptueel, is niks meer as 'n computational blok wat in wisselwerking met die uitruil oor twee verskillende strome. Ontvang markdata Stuur orde versoeke en ontvang antwoorde uit die ruil. Die mark data wat tipies ontvang lig die stelsel van die nuutste order. Dit mag dalk 'n paar ekstra inligting soos die volume tot dusver verhandel, die laaste verhandel prys en hoeveelheid vir 'n reissak bevat. Maar om 'n besluit oor die data te maak, dalk nodig die handelaar om te kyk na ou waardes of put sekere parameters van die geskiedenis. Om voorsiening te maak dat, sou 'n konvensionele stelsel 'n historiese databasis aan die mark data en gereedskap te slaan op daardie databasis te gebruik. Ontleding sou ook 'n studie van die verlede ambagte deur die handelaar te betrek. Vandaar 'n ander databasis vir die berging van die handel besluite sowel. Laaste, maar nie die minste nie, 'n grafiese koppelvlak vir die handelaar om al hierdie inligting op die skerm te sien. Die hele stelsel kan nou afgebreek word in die uitruil (s) van die eksterne wêreld Die bediener Mark data ontvang Store markdata winkel bestellings wat deur die gebruiker Aansoek Neem insette van die gebruiker, insluitend die handel besluite Interface vir die lees van die inligting, insluitend die data en bestel 'n bevel bestuurder stuur bestellings na die uitruil. Nuwe argitektuur Die tradisionele argitektuur kon nie vergroot om die behoeftes en eise van outomatiese handel met DMA. Die latency tussen oorsprong van die geval aan die orde generasie verder gaan as die dimensie van menslike beheer en het die gebied van millisekondes en mikrosekondes. So het die gereedskap om data mark te hanteer en te ontleed wat nodig is om daarby aan te pas. Bestel bestuur moet ook meer robuuste en in staat is om die hantering van baie meer bestellings per sekonde te wees. Sedert die tyd is so klein in vergelyking met menslike reaksie tyd, risikobestuur moet ook bestellings in reële tyd en in 'n heeltemal outomatiese manier te hanteer. Byvoorbeeld, selfs al is die reaksie tyd vir 'n bevel is 1 millisekonde (wat is 'n baie in vergelyking met die latencies wat ons vandag sien), die stelsel is steeds in staat is om 1000 handel besluite in 'n enkele sekonde. Dit beteken elkeen van hierdie 1000 handel besluite moet gaan deur die Risikobestuur binne dieselfde tweede tot die uitruil bereik. Dit is net 'n kwessie van kompleksiteit. Sedert die argitektuur behels nou outomatiese logika, kan 100 handelaars nou vervang word deur 'n enkele stelsel. Dit voeg skaal van die probleem. So elkeen van die logiese eenhede genereer 1000 bestellings en 100 sulke eenhede beteken 100,000 bestellings elke sekonde. Dit beteken dat die besluitneming en orde te stuur deel moet baie vinniger as die mark data ontvanger om die tempo van data aan te pas nie. Dus, die vlak van infrastruktuur wat hierdie module vereis nodig sou wees om baie beter in vergelyking met dié van 'n tradisionele stelsel (bespreek in die vorige afdeling). Vandaar die enjin wat die logika van besluitneming loop, ook bekend as die komplekse Event Processing enjin, of CEP, verskuif vanaf binne die aansoek om die bediener. Die program laag, nou, is bietjie meer as 'n gebruikerskoppelvlak vir besigtiging en die verskaffing van parameters om die CEP. Die probleem van die skaal lei ook tot 'n interessante situasie. Kom ons sê 100 verskillende logika word omgery 'n enkele mark data gebeurtenis (soos bespreek in die vorige voorbeeld). Maar daar kan wees gemeenskaplike stukkies komplekse berekeninge wat nodig het om te loop vir die meeste van die 100 logika eenhede. Byvoorbeeld, die berekening van Grieke vir opsies. As elke logika was om onafhanklik te funksioneer, sal elke eenheid dieselfde Griekse berekening wat onnodig sou opgebruik verwerker hulpbronne te doen. Ten einde te optimaliseer op die ontslag van berekening, is kompleks oorbodig berekeninge tipies af splitst in 'n aparte berekening enjin wat die Grieke bied as 'n inset aan die CEP. Hoewel die aansoek laag is in die eerste plek die oog, 'n paar van die risiko kontrole (wat nou hulpbron honger bedrywighede weens die probleem van skaal), kan afgelaai word by die toepassing laag, veral dié wat te doen het met gesonde verstand van die gebruiker insette soos vet vinger foute. Die res van die risiko tjeks word nou uitgevoer word deur 'n aparte risikobestuurstelsel (RMS) binne die Orde Bestuurder (OM), net voor die vrystelling van 'n bevel. Die probleem van die skaal beteken ook dat waar vroeër was daar 100 verskillende handelaars bestuur van hul risiko, is daar nou net een RMS stelsel om risiko te bestuur in alle logiese eenhede / strategieë. Dit kan egter 'n risiko tjeks veral wees om sekere strategieë en 'n paar kan gedoen moet word vir alle strategieë. Vandaar die RMS self behels, strategie vlak RMS (SLRMS) en globale RMS (GRMS). Dit kan ook 'n UI om die SLRMS en GRMS sien betrek. Opkoms van protokolle Met innovasies kom noodsaaklikhede. Sedert die nuwe argitektuur in staat te skaal vir baie strategieë per bediener was, die behoefte om toegang tot verskeie bestemmings uit 'n enkele bediener na vore gekom. So het die einde bestuurder aangebied verskeie adapters bestellings verskeie bestemmings data stuur en ontvang van verskeie ruil. Elke adapter tree op as 'n tolk tussen die protokol wat verstaan ​​word onder die uitruil en die protokol van kommunikasie binne die stelsel. Veelvuldige ruil bedoel verskeie adapters. Maar na 'n nuwe ruil voeg tot die stelsel, 'n nuwe adapter moet ontwerp en ingeprop in die argitektuur aangesien elke ruil volg sy enigste protokol wat is geskik vir eienskappe wat dit ruil bied. Om hierdie probleem van adapter Daarbenewens vermy, het standaard protokolle is ontwerp. Die mees prominente onder hulle is die FIX (Finansiële Information Exchange) protokol. Dit maak nie net dit hanteerbaar te maak om verskillende bestemmings op die vlieg, maar ook verminder drasties aan die Market wanneer dit kom by die koppeling met 'n nuwe bestemming. Die teenwoordigheid van standaard protokolle maak dit maklik om te integreer met derde verkopers party, vir analise of mark data voed sowel. As gevolg hiervan, die mark word baie doeltreffend as die integrasie met 'n nuwe bestemming / verkoper is nie meer 'n beperking. Daarbenewens simulasie word baie maklik as die ontvangs van data uit die reële mark en bestellings om 'n simulator stuur is net 'n kwessie van die gebruik van die FIX protokol aan te sluit op 'n simulator. Die simulator self gebou kan word in-huis of verkry vanaf 'n derde verskaffer party. Net so aangeteken data kan net teruggespeel met die adapters wat agnostikus of die data word ontvang van die lewendige mark of van 'n aangeteken datastel. Opkoms van lae latency argitekture Met die boustene van 'n algoritmiese handel stelsel in plek, die strategieë new op die vermoë om groot hoeveelhede data in reële tyd te verwerk en maak vinnige handel besluite. Maar met die koms van standaard kommunikasie protokolle soos los, die tegnologie inskrywing versperring vir die opstel van 'n algoritmiese handel lessenaar, het laer en dus meer mededingend te maak. Soos bedieners het meer geheue en hoër klokfrekwensies, die fokus verskuif na die vermindering van die latency vir besluitneming. Met verloop van tyd, die vermindering van latency is 'n noodsaaklikheid vir baie redes, soos: Strategie sin net in 'n lae latency omgewing oorlewing van die sterkste mededingers haal jy af as jy nie vinnig genoeg Die probleem is egter dat latency is regtig 'n oorkoepelende term wat verskeie omvat verskillende vertragings. Om almal te kwantifiseer in een generiese term kan gewoonlik nie veel sin. Alhoewel dit baie maklik verstaan ​​word, is dit baie moeilik om te kwantifiseer. Dit word dus al hoe belangriker hoe die probleem van die vermindering van latency is genader. As ons kyk na die basiese lewensiklus, is 'n mark data pakkie uitgegee deur die uitruil Die pakkie word oor die draad Die pakkie arriveer by 'n router op die bediener kant. Die router stuur die pakkie oor die netwerk op die bediener kant. Die pakkie arriveer op die Ethernet-poort van die bediener. Afhangende of dit UDP / TCP verwerking plaasvind en die pakkie gestroop van sy kop en sleepwaens maak sy pad na die geheue van die adapter. Die adapter ontleed dan die pakkie en vat dit na 'n formaat interne om die algoritmiese handel platform Dit pakkie nou reis deur die verskillende modules van die stelsel CEP, merk winkel, ens Die CEP ontleed en stuur 'n bevel versoek die einde versoek weer gaan deur die omgekeerde van die siklus as die mark data pakkie. Hoë latency by enige van hierdie stappe verseker 'n hoë latency vir die hele siklus. Vandaar latency optimization begin gewoonlik met die eerste stap in hierdie siklus wat in ons beheer d. w.z, die pakkie oor die draad. Die maklikste ding om hier te doen sou wees om die afstand na die bestemming te verkort deur soveel as moontlik. Colocations is fasiliteite wat deur die uitruil van die handel bediener in die nabyheid aan te bied om die uitruil. Die volgende diagram illustreer die winste wat gemaak kan word deur die sny van die afstand. Vir enige vorm van 'n hoë frekwensie strategie met betrekking tot 'n enkele bestemming, het Colocatie 'n defacto moet. Maar strategieë wat verskeie bestemmings betrek moet 'n paar deeglike beplanning. Verskeie faktore soos die tyd geneem deur die bestemming om te antwoord op bevel versoeke en sy vergelyking met die ping tyd tussen die twee bestemmings moet in ag geneem word voordat so 'n besluit. Die besluit kan net sowel afhanklik van die aard van die strategie wees. Netwerk latency is gewoonlik die eerste stap in die vermindering van algehele latency van 'n algoritmiese handel stelsel. is daar egter baie ander plekke waar die argitektuur kan geoptimaliseer word. Voortplanting latency tyd wat dit neem om die stukkies langs die draad te stuur. Beperk deur spoed van lig van die kursus. Verskeie optimalisaties is ingestel om die voortplanting latency uitmekaar te verminder van die vermindering van die fisiese afstand. Byvoorbeeld, geraamde retour tyd vir 'n gewone kabel tussen Chicago en New York is 13,1 millisekondes. Verspreiding netwerke, in Oktober 2012, bekend gemaak latency verbeterings. Bring die beraamde retour tyd om 12,98 millisekondes. Mikrogolf kommunikasie is verder deur firmas aanvaar soos Tradeworx bring die beraamde retour tyd tot 8,5 millisekondes. Let daarop dat die teoretiese minimum is ongeveer 7,5 millisekondes. Voortgesette innovasies is besig om die grense van die wetenskap en vinnige bereiking van die teoretiese perk van spoed van lig. Jongste verwikkelinge in laser kommunikasie, vroeër in die verdediging tegnologie aangeneem het verder skeer 'n reeds dunner latency deur nano sekondes oor kort afstande. Netwerk verwerking latency wat deur routers, skakelaars, ens Die volgende vlak van optimalisering in die argitektuur van 'n algoritmiese handel stelsel sou wees in die aantal hoep wat 'n pakkie sal neem om van punt A na punt B. A hop word gedefinieer as 'n gedeelte van die pad tussen bron en bestemming waartydens 'n pakkie deur 'n fisiese toestel soos 'n router of 'n skakelaar nie die geval te slaag. Byvoorbeeld, kan 'n pakkie dieselfde afstand reis via twee verskillende paaie. Maar dit kan twee hoep op die eerste pad teenoor 3 hoep op die tweede het. Die aanvaarding van die voortplanting vertraging is dieselfde die routers en switches elke stel hul eie latency en gewoonlik as 'n duim reël, meer die hoep meer is die latency bygevoeg. Netwerk verwerking latency kan ook beïnvloed word deur wat ons verwys na as lugstortings.