Haec continuatio longae fabulae est de via spinosa nostra ad creandum systema validum, summus onus, quod operationem Exchange praestat. Prima pars est hic;
Arcanum erroris
Post numerosas probationes, ratio negotiandi et purgandi updated in operando posita est, et cimex congressi sumus de quibus fabulam detectivam-mysticam scribere potuimus.
Paulo post in servo principali deducto, unus e rebus cum errore processit. Sed omnia denique in servo tergum. Contigit quod exponens in principali servo simplicem mathematicorum operationem calculandi dedit eventum negativum ex reali argument! Investigationem nostram continuavimus, et in tabulario SSE2 differentiam in uno frenum invenimus, quae rotunditatem cum punctorum numerorum fluctuantium laborat.
Utilitatem examinis scripsimus simplicem ad calculandum exponentem cum rotundo frenum posuit. Contigit quod in versione RedHat Linux, qua nos usi sumus, cimex in munere mathematico operando fuit, cum frenum infortunatum insertum est. RedHat hoc nuntiavimus, post tempus acceptum ab illis commissuram et evolvit. Error non iam occurrit, sed obscurum unde haec vel venit? Munus est reus fesetround e lingua C. Codicem nostrum diligenter enucleate ad errorem suppositum quaerendum: omnes casus possibilia coercuit; respexit ad omnia munera quae elegis usus est; defecit sessionem conatus est effingere; usus est diversis compilatoribus cum diversis options; Statica et dynamica analysi adhibita sunt.
Erroris causa reperiri non potuit.
Tunc ferramenta inhibere inceperunt: onus experimentum processuum exercebant; ram repressit; Etiam probationes procurrimus propter missionem diversi erroris in una cellula valde inconveniens. Nequiquam.
Ad extremum theoriam e mundo physicae magnificae consedimus: vis quaedam alta in centrum nostrum data volavit, parietem casui transfixit, processus percussum fecit et in ipso frenum felis foramen haerere fecit. Haec absurda theoria neutrino appellata est. Si physicae particulae longe absunt: ββneutrinos fere cum exterioribus non penitus inter se cohaerent, certe processus operationem afficere non possunt.
Cum causam deficiendi reperire non posset, "servis offendere" ab operatione iusta in casu remotum est.
Post aliquod tempus, systema tergum calidum emendare coepimus: induximus sic dicta "calida subsidia" (calidum) - replicationes asynchronas. Fluvium transactionum accipiebant quae in diversis centris notitiis collocari poterant, sed calefacientia non penitus cum aliis ministris operam dabant.
Quare hoc factum est? Si tergum servo defecerit, calidum cum servo principali ligatum novum tergum fit. Hoc est, post defectum, ratio non manet cum uno servo principali usque ad finem sessionis negotiationis.
Et cum nova versio systematis tentata et in operando facta est, in rotunditate aliqua error iterum incidit. Praeterea, crescente numero calentium ministrantium, saepius error apparere coepit. Eodem tempore venditor nihil ostendit, cum nihil certi argumenti esset.
In altera rerum analysi, theoria orta est problema ad OS referri posse. Scripsimus programma simplex, quod munus vocat in sine fine loop fesetroundmeminit hodiernus status et somnos cohibet, idque fit multis certantibus stamina. Somni parametri delectis et filorum numero, coepimus constanter frenum referre defectum, postquam circa 5 minuta currit utilitas. Sed fulmentum rubrum Hat non potuit id effingere. Probatio aliorum servientium ostendit solum eos cum quibusdam processibus esse obnoxios errori. Eodem tempore in commutatione ad novum nucleum problema solvitur. In fine, simpliciter OS reposuimus, et vera causa cimicis latebat.
Et subito anno praeterito articulum in Habre editum est." Res in eo descriptus valde similis fuit nostro, sed auctor investigationem ulterius suscepit et rationem proposuit quod error in microcode fuit. Et cum nuclei Linux renovantur, artifices microcode etiam renovant.
Longius progressus systematis
Etsi errorem solvimus, haec fabula nos ad architecturam systema retractare coegit. Ceterum a talium cimicum repetitione non fuimus muniti.
Sequentia principia fundamunt emendationes alterae ad systema reservandum:
- Non potes credere quis. Servers non recte funguntur.
- Maioris reservationis.
- Consensus prospicere. Consequens est additionis maioris reservationis.
- Duplex delicta possibilia sunt.
- Vitalitatis. Novum sto- rum calidum schema non peius esse debet quam priori. Negotiatio sine intermissione procedere debet usque ad ultimum Servum.
- In latencia exigua incrementa. Quodvis downtime ingens damna pecuniaria secumfert.
- Minimum commercium retiacula minima servare latency quam maxime potest.
- Diligens dominum novum servo in secundis.
Nullae solutiones praesto in mercatu nostro apto, et protocollum ratis adhuc in infantia erat, sic solutionem nostram creavimus.
Networking
Praeter systema reservationis modernising network commercium coepimus. Subsystem I/O in multis processibus constabat, qui pessimum ictum in jitter et latentiam habuerunt. Cum centenis processuum coniunctionibus TCP tractantibus, inter eas assidue commutare coacti sumus, et in scala micro secunda haec operatio magis edax est. Pessima autem pars est, cum processum fasciculum ad expediendum accepit, eam ad unam SystemV queue misit et eventum ab alia SystemV queue exspectavit. Cum autem numerus nodorum inest, adventus novi TCP fasciculi in uno processu et acceptio notitiarum in queue in alio duo certatim eventus pro OS repraesentant. In hoc casu, si processus physici ad utrumque opus non praesto sint, unus discursum erit, et secundus in exspectatione queue collocabitur. Impossibile est consequentia praedicere.
In eiusmodi adiunctis, processus dynamicus prioritatis imperium adhiberi potest, sed hoc usus postulat ratio intensiva subsidiorum. Quam ob rem ad unum filum utentes epoll classico mutavimus, hoc celeritas valde auxit et temporis processui transactionem redegit. Disiunctis etiam processibus communicationis network et communicationis per SystemV removimus, signanter numerum vocationis systematis redegit et prioritates operationum regere coepit. In solo I/O subsystem, circiter 8-17 microseconds servare potuit, secundum missionem. Hoc unum liciatorium schema mutatum tunc est adhibitum, unum epoll linum cum margine satis est omnibus necessariis inservire.
Transaction Processing
Crescens pondus in systemate nostro progressionis fere omnium suarum partium requirebat. Sed, proh dolor, torporis celeritatum horologii processus in incrementis proximis annis non amplius effecit ut processus capitis-in scandere posset. Ergo constituimus processum Engine in tres gradus dividere, cum frequentissima ratio earum sit ratio iniecta, quae disponibilitatem pecuniarum in rationibus aestimat et res ipsas efficit. Pecunia autem potest esse in diversis currencies, et oportuit indicare quomodo processus petitionum dividatur.
Solutio logica eam per monetam dividere est: una artificia in dollariis, altera in libras, tertia in nummis. Sed si cum tali schemate duae transactiones ad varias currencies mercandas mittuntur, tunc quaestio viduli desynchronizationis oritur. Sed synchronisatio difficilis et sumptuosa est. Ergo seorsim peris et seorsim per instrumenta testa. Obiter maxime occidentales commutationes non habent munus reprimendi periculorum tam acute ac nos, toties hoc in offline fit. Non opus est verificationem ad efficiendum online.
Explicemus exemplo. Mercator $30 emere vult, et petitio ad sanationem transactionis accedit: nos inspicimus, an negotiatori huic modo negotianti liceat et an iura necessaria habeat. Si omnia ordinantur, petitio ad periculum accedit ratio verificationis, i.e. ad reprimendam sufficientiam pecuniarum concludere transactionem. Est nota quod moles requiritur currently impeditur. Postulatio dein transmittuntur ad systema negotiandi, quod rem gestam approbat vel improbat. Dicamus rem approbatam esse - deinde periculum verificationis ratio notarum pecuniam non impeditam et rubles in dollarios convertunt.
In genere, periculum systematis inhibitionis algorithmorum complexum continet et magnam vim calculorum intensivarum valde subsidiorum efficit, nec simpliciter "libras rationis" continet, sicut primo intuitu videri potest.
Cum processum Engine in gradus dividere coepimus, problema invenimus: codicem, qui tunc temporis praesto erat, eadem notitiarum copia in convalidationibus et gradibus verificationis usus est, quae totum codicem basim rescribere requirebat. Quam ob rem technicam instituendi ab hodiernis processibus mutuati sumus: unaquaeque earum in parvas gradus dividitur et plures actiones in uno cyclo parallelae peraguntur.
Post parvam codicis aptationem, fistulam ad processui paralleli transactionis creavimus, in quo transactiones in quattuor gradus pipelini dividebantur: commercium retis, sanationis, executionis et publicationis effectus.
Intueamur exemplum. Duo systemata processus, Vide et parallela. Prima transactio advenit et ad sanandum in utroque systemate arcessitur. Secunda transactio statim advenit: in systemate parallelo statim ad opus sumitur, et in systemate sequenti ponitur in queue expectans primam transactionem ut per stadium currentem processui. Hoc est, principale processui pipeline utilissimum est quod nos rem gestam queue velocius processurum esse.
Hoc modo conscendimus cum systemate ASTS+.
Verum, non omnia tam levia cum traducibus vel. Dicamus nos habere transactionem quae notitias vestit in negotio vicino, hoc est condicio typica commutationis. Talis transactionis in pipelino exsecutioni mandari non potest quia alios afficit. Haec condicio aleam data dicitur, et tales transactiones separatim discursum sunt: ββcum "celeriter" res in queue excurrunt, cessat pipeline, ratio rem "tardi" processit, et tunc iterum incipit pipeline. Fortunate, minima proportio talium negotiorum in altiore fluxu est, ita raro pipeline cessat ut altiore effectui non afficiat.
Tunc problema tria stamina executionis synchronum solvere incepimus. Effectus erat systema secundum quiddam inauris in cellulis fixum-amplentibus. In hoc systemate omnia celeritati processui subiecta sunt: ββnotitia non est expressa.
- Omnes ineuntes in scaena reticuli facis destinatio intrant.
- Eas collocamus in apparatu et notamus ut praesto pro spectaculis #1.
- Secunda transactio advenit, iterum praesto est pro scaena N. 1;
- Primus processus filo videt transactions promptos, eos processus, eosque movet ad proximum stadium secundi sequelae processus.
- Tunc procedit prima transactione et marcet cellam respondentem
deletedβ nunc ad novos usus praesto est.
Tota queue hoc modo processit.
Processus cuiusque stadii unitates vel decem microseconds accipit. Et si normae OS synchronisationi utamur technis, tunc temporis in ipsa synchronisation amittemus. Quam ob rem nos spinlock uti coepimus. Sed haec est pessima forma in systemate reali temporis, et hoc stricte RedHat non suadet facere, ideo spinlock pro 100 ms applicamus, et deinde ad modum semaphoris mutandum est ad tollendam facultatem deadlock.
Quam ob rem perficiendo circiter VIII decies centena millia transactionum secundo consecuti sumus. Et ad litteram duo menses post in de LMAX Disruptor ambitus eadem functione vidimus descriptionem.
Plures autem stamina in uno gradu esse possunt. Omnia gesta singillatim in ordinem recipiebantur. Quam ob rem, cacumina perficiendi ab 18 milibus ad 50 milia negotiorum secundo aucta sunt.
Ratio commutationem periculo procuratio
Nullus modus perfectionis est, et mox iterum modernisatio incepit: intra ASTS+ compagem, periculum administrationis ac operationes componere in partes autonomas coepimus movere. Architectura nova et periculum hierarchicum novum exemplar enucleavimus flexibile, et classis ubicumque fieri potest uti conati sumus fixed_point pro double.
Sed quaestio statim orta est: quomodo synchronum esse totum negotium logicum, quod multis annis laboratum est, et ad novam rationem transferre? Quam ob rem prima versio prototypum novi systematis relinquendum erat. Secunda versio, quae nunc in productione operatur, in eodem codice nititur, qui in negotiatione et periculo partium operatur. In evolutione, difficillimum factu erat inter duas versiones merge. Collega noster Evgeniy Mazurenok hanc operationem singulis hebdomadibus peregit et singulis diebus diutissime execratus est.
Cum novum systema eligendum, statim problema commercii solvendum habuimus. Cum data bus eligendo, necesse erat ut jitterarum stabilium et minimam latentiam curaret. InfiniBand RDMA retis huic aptissimum erat: mediocris processus tempus est 4 temporibus minus quam in 10 G reticulis Aer. Sed quid vere captus nos differat centones - 99 et 99,9.
Nempe InfiniBand habet provocationes. Uno alio api - ibverbs pro totidem. Secundo, nullae fere sunt late patentes fons solutionum nuntiantium. Prototypum nostrum facere conati sumus, sed difficillimum evasit, unde solutionem commercialem elegimus - Confinity Low Latency Nuntius (olim IBM MQ LLM).
Tum munus recte dividendi ratio periculi orta est. Si Risk Engine simpliciter removes et nodi medium non efficiunt, transactiones ex duobus fontibus misceri possunt.
Sic dictae solutiones Ultra Low Latency modum reordinandi habent: transactiones e duobus fontibus ordinari possunt in ordine recepto requisito, hoc effectum est utentes alveum separatum ad informationes de ordine conferendas. Sed hoc modo nondum utimur: totum processum implicat et in pluribus solutionibus omnino non continetur. Praeterea singulae negotii momenta congruentia assignari oportebit, et in nostro schemate haec mechanismus difficillimum est ad recte efficiendum. Propterea schema classicum usi sumus cum nuntio sectoris, id est cum mittente qui nuntios inter Engine Risk distribuit.
Secunda quaestio ad clientem accessum relata est: si plures sunt Risk Gateways, cliens singulis earum coniungere debet, et haec mutatio ad clientem tabulatum postulabit. Ab hac hac scaena discedere voluimus, sic consilium current Risk Gateway tota notitia amnis processit. Hoc maximum throughput magnopere limitat, sed valde integrationem systematis simplicificat.
duplicatione
Nostra ratio non debet unum punctum defectionis habere, hoc est, omnia reduplicari, incluso nuntio sectorum. Hanc problema utentes systematis CLLM solvimus: botrum RCMS continet in quo duae litterae in modo servili laborare possunt, et cum unus deficit, ratio automatice ad alterum permutat.
Tergum Mauris interdum cum opus
InfiniBand optimized pro operatione retis localis, hoc est, pro instrumento eculei connectendi, et retis InfiniBand inter duo data centra geographica distributa collocari non potest. Itaque pontem/distatorem/promissionis, quae ad nuntium repositionis per regulares retia Aernetanorum coniungitur, et omnes negotiorum ad alterum IB retis disponit. Cum migrare ex notitia centrum necesse est, eligere possumus quae centrum ad operandum nunc est.
results
Haec omnia non statim facta sunt: ββvarias iterationes novas architecturae enucleandi suscepit. Prototypum mense uno creavimus, sed plus duobus annis accepit ut in condicionem operantes. Conati sumus consequi optimum compromissum inter augendae transactionis processus tempus et systematis firmitatem augendam.
Cum systema graviter renovatum esset, notitias receptas ex duobus independens fontibus implevimus. Si nuntius horreorum aliqua de causa recte non operatur, ex altero fonte - ex Engine Risk capere potes. Hoc principium in tota ratione servatur.
Inter cetera clientem API conservare potuimus ut neque sectores neque alius quisquam notabilem laborem novae architecturae requireret. Interfaces variare debebamus, sed notabiles mutationes exemplar operantis facere non oportebat.
Praesens litera nostrae tribunalis Rebus appellavimus - ut abbreviationem pro duabus innovationibus notissimis in architectura, Engine Risk et BUS.
Initio solum defensionem partem collocare voluimus, sed effectus erat ratio distributa ingens. Clientes nunc possunt mutuam esse cum aut Porta Trade, aut Porta Purgare, aut utrumque.
Quod tandem consecuti sumus;
Reduci latency massa. Cum parvo volumine negotiorum, eadem ratio cum versione praecedente operatur, sed simul multo altiori onere resistere potest.
Picus perficientur auctus est ab 50 milibus ad 180 milia negotiorum secundo. Additur incrementa impedita unico ordinis congruens rivo.
Duplex modus est ad ulteriorem emendationem: parallelising adaptans et mutans viam quae operatur cum porta. Nunc omnes Gateviae operantur secundum schema replicationis, quod sub tali onere regulariter operari desinit.
Denique consilium aliquod dare possum iis qui systemata incepti compleant;
- Pessimum omni tempore paretur. Problemata semper improviso oriuntur.
- Solet impossibile est architecturam cito reformare. Praesertim si maximam fidem per plures indices consequi debes. Quo magis nodi, eo plus subsidii necessariae sunt.
- Omnis consuetudo et solutiones proprietatis additas facultates requirent ad investigationem, sustentationem et sustentationem.
- Quaestiones de systematis firmitate et recuperatione post delicta solvendis noli differre, eas in stadio initiali considerare.
Source: www.habr.com