మాస్కో ఎక్స్ఛేంజ్ యొక్క ట్రేడింగ్ మరియు క్లియరింగ్ సిస్టమ్ యొక్క నిర్మాణం యొక్క పరిణామం. 1 వ భాగము

అందరికి వందనాలు! నా పేరు సెర్గీ కోస్టాన్‌బావ్, ఎక్స్ఛేంజ్‌లో నేను వ్యాపార వ్యవస్థ యొక్క ప్రధాన భాగాన్ని అభివృద్ధి చేస్తున్నాను.

హాలీవుడ్ సినిమాలు న్యూయార్క్ స్టాక్ ఎక్స్ఛేంజ్‌ని చూపించినప్పుడు, ఇది ఎల్లప్పుడూ ఇలా కనిపిస్తుంది: జనం గుంపులు, అందరూ ఏదో అరుస్తున్నారు, కాగితాలు ఊపడం, పూర్తి గందరగోళం జరుగుతోంది. మాస్కో ఎక్స్ఛేంజ్‌లో ఇది ఎప్పుడూ జరగలేదు, ఎందుకంటే ట్రేడింగ్ ప్రారంభం నుండి ఎలక్ట్రానిక్ పద్ధతిలో నిర్వహించబడింది మరియు స్పెక్ట్రా (ఫారెక్స్ మార్కెట్) మరియు ASTS (విదేశీ మార్పిడి, స్టాక్ మరియు మనీ మార్కెట్) అనే రెండు ప్రధాన ప్లాట్‌ఫారమ్‌లపై ఆధారపడి ఉంటుంది. మరియు ఈ రోజు నేను ASTS ట్రేడింగ్ మరియు క్లియరింగ్ సిస్టమ్ యొక్క ఆర్కిటెక్చర్ యొక్క పరిణామం గురించి, వివిధ పరిష్కారాలు మరియు ఫలితాల గురించి మాట్లాడాలనుకుంటున్నాను. కథ చాలా పొడవుగా ఉంటుంది కాబట్టి రెండు భాగాలుగా చేయవలసి వచ్చింది.

మేము అన్ని తరగతుల ఆస్తులను వర్తకం చేసే మరియు పూర్తి స్థాయి మార్పిడి సేవలను అందించే ప్రపంచంలోని కొన్ని ఎక్స్ఛేంజీలలో ఒకటి. ఉదాహరణకు, గత సంవత్సరం మేము బాండ్ ట్రేడింగ్ పరిమాణంలో ప్రపంచంలో రెండవ స్థానంలో ఉన్నాం, అన్ని స్టాక్ ఎక్స్ఛేంజీలలో 25వ స్థానం, పబ్లిక్ ఎక్స్ఛేంజీలలో క్యాపిటలైజేషన్‌లో 13వ స్థానం.

ప్రొఫెషనల్ ట్రేడింగ్ పాల్గొనేవారికి, ప్రతిస్పందన సమయం, సమయ పంపిణీ యొక్క స్థిరత్వం (జిట్టర్) మరియు మొత్తం కాంప్లెక్స్ యొక్క విశ్వసనీయత వంటి పారామితులు కీలకం. మేము ప్రస్తుతం రోజుకు పది లక్షల లావాదేవీలను ప్రాసెస్ చేస్తున్నాము. సిస్టమ్ కెర్నల్ ద్వారా ప్రతి లావాదేవీని ప్రాసెస్ చేయడానికి పదుల మైక్రోసెకన్లు పడుతుంది. వాస్తవానికి, నూతన సంవత్సర పండుగ లేదా సెర్చ్ ఇంజన్లలో మొబైల్ ఆపరేటర్లు మా కంటే ఎక్కువ పనిభారాన్ని కలిగి ఉంటారు, కానీ పనిభారం పరంగా, పైన పేర్కొన్న లక్షణాలతో పాటు, కొంతమంది మాతో పోల్చవచ్చు, అది నాకు అనిపిస్తుంది. అదే సమయంలో, సిస్టమ్ సెకనుకు వేగాన్ని తగ్గించకుండా ఉండటం, ఖచ్చితంగా స్థిరంగా పని చేయడం మరియు వినియోగదారులందరూ సమాన స్థాయిలో ఉండటం మాకు ముఖ్యం.

ఒక చిన్న చరిత్ర

1994లో, ఆస్ట్రేలియన్ ASTS వ్యవస్థ మాస్కో ఇంటర్‌బ్యాంక్ కరెన్సీ ఎక్స్ఛేంజ్ (MICEX)లో ప్రారంభించబడింది మరియు ఆ క్షణం నుండి ఎలక్ట్రానిక్ ట్రేడింగ్ యొక్క రష్యన్ చరిత్రను లెక్కించవచ్చు. 1998లో, ఇంటర్నెట్ ట్రేడింగ్‌ను పరిచయం చేయడానికి ఎక్స్ఛేంజ్ ఆర్కిటెక్చర్ ఆధునికీకరించబడింది. అప్పటి నుండి, అన్ని సిస్టమ్‌లు మరియు సబ్‌సిస్టమ్‌లలో కొత్త పరిష్కారాలు మరియు నిర్మాణ మార్పుల అమలు వేగం ఊపందుకుంది.

ఆ సంవత్సరాల్లో, ఎక్స్ఛేంజ్ సిస్టమ్ హై-ఎండ్ హార్డ్‌వేర్ - అల్ట్రా-రిలబుల్ HP సూపర్‌డోమ్ 9000 సర్వర్‌లపై పనిచేసింది (నిర్మించబడింది PA-RISC), ఇందులో ఖచ్చితంగా ప్రతిదీ నకిలీ చేయబడింది: ఇన్‌పుట్/అవుట్‌పుట్ సబ్‌సిస్టమ్‌లు, నెట్‌వర్క్, RAM (వాస్తవానికి, RAM యొక్క RAID శ్రేణి ఉంది), ప్రాసెసర్‌లు (హాట్-స్వాప్ చేయదగినవి). యంత్రాన్ని ఆపకుండానే ఏదైనా సర్వర్ భాగాన్ని మార్చడం సాధ్యమైంది. మేము ఈ పరికరాలపై ఆధారపడతాము మరియు వాటిని వాస్తవంగా ఫెయిల్-సురక్షితంగా పరిగణించాము. ఆపరేటింగ్ సిస్టమ్ Unix-వంటి HP UX సిస్టమ్.

కానీ దాదాపు 2010 నుండి, హై-ఫ్రీక్వెన్సీ ట్రేడింగ్ (HFT) లేదా హై-ఫ్రీక్వెన్సీ ట్రేడింగ్ అని పిలువబడే ఒక దృగ్విషయం ఉద్భవించింది - కేవలం చెప్పాలంటే, స్టాక్ ఎక్స్ఛేంజ్ రోబోట్లు. కేవలం 2,5 సంవత్సరాలలో, మా సర్వర్‌లపై లోడ్ 140 రెట్లు పెరిగింది.

పాత ఆర్కిటెక్చర్ మరియు పరికరాలతో అటువంటి భారాన్ని తట్టుకోవడం అసాధ్యం. ఏదో ఒకవిధంగా స్వీకరించడం అవసరం.

Начало

మార్పిడి వ్యవస్థకు అభ్యర్థనలను రెండు రకాలుగా విభజించవచ్చు:

• లావాదేవీలు. మీరు డాలర్లు, షేర్లు లేదా మరేదైనా కొనుగోలు చేయాలనుకుంటే, మీరు ట్రేడింగ్ సిస్టమ్‌కు లావాదేవీని పంపుతారు మరియు విజయం గురించి ప్రతిస్పందనను అందుకుంటారు.
• సమాచార అభ్యర్థనలు. మీరు ప్రస్తుత ధరను కనుగొనాలనుకుంటే, ఆర్డర్ బుక్ లేదా సూచికలను వీక్షించండి, ఆపై సమాచార అభ్యర్థనలను పంపండి.

క్రమపద్ధతిలో, వ్యవస్థ యొక్క ప్రధాన భాగాన్ని మూడు స్థాయిలుగా విభజించవచ్చు:

• బ్రోకర్లు మరియు క్లయింట్లు పని చేసే క్లయింట్ స్థాయి. అవన్నీ యాక్సెస్ సర్వర్‌లతో పరస్పర చర్య చేస్తాయి.
• గేట్‌వే సర్వర్లు అన్ని సమాచార అభ్యర్థనలను స్థానికంగా ప్రాసెస్ చేసే కాషింగ్ సర్వర్‌లు. స్బేర్‌బ్యాంక్ షేర్లు ప్రస్తుతం ఏ ధరతో ట్రేడ్ అవుతున్నాయో తెలుసుకోవాలనుకుంటున్నారా? అభ్యర్థన యాక్సెస్ సర్వర్‌కు వెళుతుంది.
• కానీ మీరు షేర్లను కొనుగోలు చేయాలనుకుంటే, అభ్యర్థన సెంట్రల్ సర్వర్ (ట్రేడ్ ఇంజిన్)కి వెళుతుంది. ప్రతి రకమైన మార్కెట్‌కు అటువంటి సర్వర్ ఒకటి ఉంది, అవి కీలక పాత్ర పోషిస్తాయి, వారి కోసం మేము ఈ వ్యవస్థను సృష్టించాము.

ట్రేడింగ్ సిస్టమ్ యొక్క ప్రధాన అంశం ఒక తెలివైన ఇన్-మెమరీ డేటాబేస్, దీనిలో అన్ని లావాదేవీలు మార్పిడి లావాదేవీలు. బేస్ C లో వ్రాయబడింది, బాహ్య డిపెండెన్సీలు మాత్రమే libc లైబ్రరీ మరియు డైనమిక్ మెమరీ కేటాయింపులు లేవు. ప్రాసెసింగ్ సమయాన్ని తగ్గించడానికి, సిస్టమ్ శ్రేణుల స్టాటిక్ సెట్‌తో మరియు స్టాటిక్ డేటా రీలొకేషన్‌తో ప్రారంభమవుతుంది: మొదట, ప్రస్తుత రోజు మొత్తం డేటా మెమరీలోకి లోడ్ చేయబడుతుంది మరియు తదుపరి డిస్క్ యాక్సెస్ నిర్వహించబడదు, అన్ని పని మెమరీలో మాత్రమే నిర్వహించబడుతుంది. సిస్టమ్ ప్రారంభమైనప్పుడు, అన్ని సూచన డేటా ఇప్పటికే క్రమబద్ధీకరించబడింది, కాబట్టి శోధన చాలా సమర్థవంతంగా పని చేస్తుంది మరియు రన్‌టైమ్‌లో తక్కువ సమయం పడుతుంది. అన్ని టేబుల్‌లు డైనమిక్ డేటా స్ట్రక్చర్‌ల కోసం అనుచిత జాబితాలు మరియు చెట్లతో తయారు చేయబడ్డాయి, తద్వారా వాటికి రన్‌టైమ్‌లో మెమరీ కేటాయింపు అవసరం లేదు.

మా ట్రేడింగ్ మరియు క్లియరింగ్ సిస్టమ్ అభివృద్ధి చరిత్రను క్లుప్తంగా చూద్దాం.
ట్రేడింగ్ మరియు క్లియరింగ్ సిస్టమ్ ఆర్కిటెక్చర్ యొక్క మొదటి వెర్షన్ యునిక్స్ ఇంటరాక్షన్ అని పిలవబడే వాటిపై నిర్మించబడింది: షేర్డ్ మెమరీ, సెమాఫోర్స్ మరియు క్యూలు ఉపయోగించబడ్డాయి మరియు ప్రతి ప్రక్రియలో ఒకే థ్రెడ్ ఉంటుంది. ఈ విధానం 1990ల ప్రారంభంలో విస్తృతంగా వ్యాపించింది.

సిస్టమ్ యొక్క మొదటి సంస్కరణలో గేట్‌వే యొక్క రెండు స్థాయిలు మరియు ట్రేడింగ్ సిస్టమ్ యొక్క సెంట్రల్ సర్వర్ ఉన్నాయి. పని విధానం ఇలా ఉంది:

• క్లయింట్ ఒక అభ్యర్థనను పంపుతుంది, అది గేట్‌వేకి చేరుకుంటుంది. ఇది ఫార్మాట్ యొక్క చెల్లుబాటును తనిఖీ చేస్తుంది (కానీ డేటా కాదు) మరియు తప్పు లావాదేవీలను తిరస్కరిస్తుంది.
• సమాచార అభ్యర్థన పంపబడితే, అది స్థానికంగా అమలు చేయబడుతుంది; మేము లావాదేవీ గురించి మాట్లాడుతున్నట్లయితే, అది సెంట్రల్ సర్వర్‌కు దారి మళ్లించబడుతుంది.
• ట్రేడింగ్ ఇంజిన్ అప్పుడు లావాదేవీని ప్రాసెస్ చేస్తుంది, స్థానిక మెమరీని సవరిస్తుంది మరియు ప్రత్యేక ప్రతిరూపణ ఇంజిన్‌ను ఉపయోగించి ప్రతిరూపణ కోసం లావాదేవీకి మరియు లావాదేవీకి ప్రతిస్పందనను పంపుతుంది.
• గేట్‌వే సెంట్రల్ నోడ్ నుండి ప్రతిస్పందనను అందుకుంటుంది మరియు దానిని క్లయింట్‌కు ఫార్వార్డ్ చేస్తుంది.
• కొంత సమయం తర్వాత, గేట్‌వే ప్రతిరూపణ విధానం ద్వారా లావాదేవీని అందుకుంటుంది మరియు ఈసారి అది స్థానికంగా అమలు చేస్తుంది, దాని డేటా నిర్మాణాలను మారుస్తుంది, తద్వారా తదుపరి సమాచార అభ్యర్థనలు తాజా డేటాను ప్రదర్శిస్తాయి.

వాస్తవానికి, ఇది ప్రతిరూపణ నమూనాను వివరిస్తుంది, దీనిలో గేట్‌వే వ్యాపార వ్యవస్థలో చేసిన చర్యలను పూర్తిగా ప్రతిబింబిస్తుంది. బహుళ యాక్సెస్ నోడ్‌లలో లావాదేవీలు ఒకే క్రమంలో అమలు చేయబడేలా ప్రత్యేక ప్రతిరూపణ ఛానెల్ నిర్ధారిస్తుంది.

కోడ్ సింగిల్-థ్రెడ్ అయినందున, చాలా మంది క్లయింట్‌లకు సేవ చేయడానికి ప్రాసెస్ ఫోర్క్‌లతో కూడిన క్లాసిక్ స్కీమ్ ఉపయోగించబడింది. అయినప్పటికీ, మొత్తం డేటాబేస్‌ను ఫోర్క్ చేయడం చాలా ఖరీదైనది, కాబట్టి TCP సెషన్‌ల నుండి ప్యాకెట్‌లను సేకరించి వాటిని ఒక క్యూ (SystemV మెసేజ్ క్యూ)కి బదిలీ చేసే తేలికపాటి సేవా ప్రక్రియలు ఉపయోగించబడ్డాయి. గేట్‌వే మరియు ట్రేడ్ ఇంజిన్ ఈ క్యూతో మాత్రమే పని చేస్తాయి, అమలు కోసం అక్కడి నుండి లావాదేవీలను తీసుకుంది. దీనికి ప్రతిస్పందనను పంపడం ఇకపై సాధ్యం కాదు, ఎందుకంటే ఏ సేవా ప్రక్రియ దీన్ని చదవాలో స్పష్టంగా లేదు. కాబట్టి మేము ఒక ఉపాయాన్ని ఆశ్రయించాము: ప్రతి ఫోర్క్డ్ ప్రాసెస్ దానికదే ప్రతిస్పందన క్యూను సృష్టించింది మరియు ఇన్‌కమింగ్ క్యూలో అభ్యర్థన వచ్చినప్పుడు, ప్రతిస్పందన క్యూ కోసం ట్యాగ్ వెంటనే దానికి జోడించబడుతుంది.

క్యూ నుండి క్యూకి పెద్ద మొత్తంలో డేటాను నిరంతరం కాపీ చేయడం సమస్యలను సృష్టించింది, ప్రత్యేకించి సమాచార అభ్యర్థనలకు విలక్షణమైనది. అందువల్ల, మేము మరొక ఉపాయాన్ని ఉపయోగించాము: ప్రతిస్పందన క్యూతో పాటు, ప్రతి ప్రక్రియ భాగస్వామ్య మెమరీని కూడా సృష్టించింది (SystemV షేర్డ్ మెమరీ). ప్యాకేజీలు దానిలో ఉంచబడ్డాయి మరియు ఒక ట్యాగ్ మాత్రమే క్యూలో నిల్వ చేయబడుతుంది, ఇది అసలు ప్యాకేజీని కనుగొనడానికి అనుమతిస్తుంది. ఇది ప్రాసెసర్ కాష్‌లో డేటాను నిల్వ చేయడానికి సహాయపడింది.

SystemV IPC క్యూ, మెమరీ మరియు సెమాఫోర్ ఆబ్జెక్ట్‌ల స్థితిని వీక్షించడానికి యుటిలిటీలను కలిగి ఉంటుంది. ఒక నిర్దిష్ట సమయంలో సిస్టమ్‌లో ఏమి జరుగుతుందో, ఎక్కడ ప్యాకెట్లు పేరుకుపోయాయి, ఏమి నిరోధించబడ్డాయి మొదలైనవాటిని అర్థం చేసుకోవడానికి మేము దీన్ని చురుకుగా ఉపయోగించాము.

మొదటి ఆధునికీకరణలు

అన్నింటిలో మొదటిది, మేము సింగిల్-ప్రాసెస్ గేట్‌వేని వదిలించుకున్నాము. దీని ముఖ్యమైన లోపం ఏమిటంటే, ఇది ఒక ప్రతిరూపణ లావాదేవీని లేదా క్లయింట్ నుండి ఒక సమాచార అభ్యర్థనను నిర్వహించగలదు. మరియు లోడ్ పెరిగేకొద్దీ, గేట్‌వే అభ్యర్థనలను ప్రాసెస్ చేయడానికి ఎక్కువ సమయం పడుతుంది మరియు ప్రతిరూపణ ప్రవాహాన్ని ప్రాసెస్ చేయదు. అదనంగా, క్లయింట్ లావాదేవీని పంపినట్లయితే, మీరు దాని చెల్లుబాటును తనిఖీ చేసి, దానిని మరింత ముందుకు పంపాలి. అందువల్ల, మేము సింగిల్ గేట్‌వే ప్రాసెస్‌ను సమాంతరంగా అమలు చేయగల బహుళ భాగాలతో భర్తీ చేసాము: RW లాకింగ్‌ని ఉపయోగించి షేర్డ్ మెమరీ ప్రాంతంలో ఒకదానికొకటి స్వతంత్రంగా నడుస్తున్న బహుళ-థ్రెడ్ సమాచారం మరియు లావాదేవీ ప్రక్రియలు. మరియు అదే సమయంలో మేము డిస్పాచ్ మరియు రెప్లికేషన్ ప్రక్రియలను ప్రవేశపెట్టాము.

అధిక ఫ్రీక్వెన్సీ ట్రేడింగ్ ప్రభావం

ఆర్కిటెక్చర్ యొక్క పై వెర్షన్ 2010 వరకు ఉనికిలో ఉంది. ఇంతలో, మేము HP సూపర్‌డోమ్ సర్వర్‌ల పనితీరుతో సంతృప్తి చెందలేదు. అదనంగా, PA-RISC ఆర్కిటెక్చర్ వాస్తవంగా చనిపోయింది; విక్రేత ఎటువంటి ముఖ్యమైన అప్‌డేట్‌లను అందించలేదు. ఫలితంగా, మేము HP UX/PA RISC నుండి Linux/x86కి మారడం ప్రారంభించాము. యాక్సెస్ సర్వర్‌ల అనుసరణతో పరివర్తన ప్రారంభమైంది.

మరి వాస్తును ఎందుకు మార్చాల్సి వచ్చింది? వాస్తవం ఏమిటంటే అధిక-ఫ్రీక్వెన్సీ ట్రేడింగ్ సిస్టమ్ కోర్‌లో లోడ్ ప్రొఫైల్‌ను గణనీయంగా మార్చింది.

మేము ఒక చిన్న లావాదేవీని కలిగి ఉన్నామని చెప్పండి, అది గణనీయమైన ధర మార్పుకు కారణమైంది - ఎవరైనా సగం బిలియన్ డాలర్లు కొనుగోలు చేసారు. కొన్ని మిల్లీసెకన్ల తర్వాత, మార్కెట్ భాగస్వాములందరూ దీనిని గమనించి, దిద్దుబాటు చేయడం ప్రారంభిస్తారు. సహజంగానే, అభ్యర్థనలు భారీ క్యూలో వరుసలో ఉంటాయి, సిస్టమ్ క్లియర్ చేయడానికి చాలా సమయం పడుతుంది.

ఈ 50 ms విరామంలో, సగటు వేగం సెకనుకు 16 వేల లావాదేవీలు. మేము విండోను 20 ఎంఎస్‌లకు తగ్గిస్తే, గరిష్టంగా 90 వేల లావాదేవీలతో సెకనుకు సగటున 200 వేల లావాదేవీల వేగం అందుతుంది. మరో మాటలో చెప్పాలంటే, ఆకస్మిక పేలుళ్లతో లోడ్ స్థిరంగా ఉండదు. మరియు అభ్యర్థనల క్యూ ఎల్లప్పుడూ త్వరగా ప్రాసెస్ చేయబడాలి.

అయితే అక్కడ క్యూ ఎందుకు ఉంది? కాబట్టి, మా ఉదాహరణలో, చాలా మంది వినియోగదారులు ధర మార్పును గమనించారు మరియు తదనుగుణంగా లావాదేవీలను పంపారు. వారు గేట్‌వేకి వస్తారు, అది వాటిని సీరియల్ చేస్తుంది, ఒక నిర్దిష్ట క్రమాన్ని సెట్ చేస్తుంది మరియు వాటిని నెట్‌వర్క్‌కు పంపుతుంది. రూటర్‌లు ప్యాకెట్‌లను షఫుల్ చేసి వాటిని ఫార్వార్డ్ చేస్తాయి. ఎవరి ప్యాకేజీ మొదట వచ్చింది, ఆ లావాదేవీ "గెలిచింది". ఫలితంగా, ఎక్స్ఛేంజ్ క్లయింట్లు అదే లావాదేవీని అనేక గేట్‌వేల నుండి పంపినట్లయితే, దాని వేగవంతమైన ప్రాసెసింగ్ అవకాశాలు పెరిగాయని గమనించడం ప్రారంభించారు. త్వరలో, మార్పిడి రోబోట్‌లు అభ్యర్థనలతో గేట్‌వేపై బాంబు దాడి చేయడం ప్రారంభించాయి మరియు లావాదేవీల హిమపాతం ఏర్పడింది.

పరిణామం యొక్క కొత్త రౌండ్

విస్తృతమైన పరీక్ష మరియు పరిశోధన తర్వాత, మేము రియల్ టైమ్ ఆపరేటింగ్ సిస్టమ్ కెర్నల్‌కి మారాము. దీని కోసం మేము RedHat Enterprise MRG Linuxని ఎంచుకున్నాము, ఇక్కడ MRG అంటే మెసేజింగ్ రియల్ టైమ్ గ్రిడ్. నిజ-సమయ పాచెస్ యొక్క ప్రయోజనం ఏమిటంటే అవి సాధ్యమైనంత వేగంగా అమలు చేయడానికి సిస్టమ్‌ను ఆప్టిమైజ్ చేస్తాయి: అన్ని ప్రక్రియలు FIFO క్యూలో వరుసలో ఉంటాయి, కోర్లను వేరు చేయవచ్చు, ఎజెక్షన్‌లు ఉండవు, అన్ని లావాదేవీలు ఖచ్చితమైన క్రమంలో ప్రాసెస్ చేయబడతాయి.

ఎరుపు - సాధారణ కెర్నల్‌లో క్యూతో పని చేయడం, ఆకుపచ్చ - నిజ-సమయ కెర్నల్‌లో పని చేయడం.

కానీ సాధారణ సర్వర్‌లలో తక్కువ జాప్యాన్ని సాధించడం అంత సులభం కాదు:

• SMI మోడ్, ఇది x86 ఆర్కిటెక్చర్‌లో ముఖ్యమైన పెరిఫెరల్స్‌తో పనిచేయడానికి ఆధారం, ఇది బాగా జోక్యం చేసుకుంటుంది. అన్ని రకాల హార్డ్‌వేర్ ఈవెంట్‌ల ప్రాసెసింగ్ మరియు భాగాలు మరియు పరికరాల నిర్వహణ అనేది పారదర్శక SMI మోడ్ అని పిలవబడే ఫర్మ్‌వేర్ ద్వారా నిర్వహించబడుతుంది, దీనిలో ఫర్మ్‌వేర్ ఏమి చేస్తుందో ఆపరేటింగ్ సిస్టమ్ చూడదు. నియమం ప్రకారం, అన్ని ప్రధాన విక్రేతలు SMI ప్రాసెసింగ్ మొత్తాన్ని తగ్గించడానికి అనుమతించే ఫర్మ్‌వేర్ సర్వర్‌ల కోసం ప్రత్యేక పొడిగింపులను అందిస్తారు.
• ప్రాసెసర్ ఫ్రీక్వెన్సీ యొక్క డైనమిక్ నియంత్రణ ఉండకూడదు, ఇది అదనపు పనికిరాని సమయానికి దారితీస్తుంది.
• ఫైల్ సిస్టమ్ లాగ్ ఫ్లష్ అయినప్పుడు, కెర్నల్‌లో కొన్ని ప్రక్రియలు జరుగుతాయి, అది అనూహ్య ఆలస్యాన్ని కలిగిస్తుంది.
• మీరు CPU అనుబంధం, అంతరాయ అనుబంధం, NUMA వంటి వాటిపై శ్రద్ధ వహించాలి.

రియల్ టైమ్ ప్రాసెసింగ్ కోసం Linux హార్డ్‌వేర్ మరియు కెర్నల్‌ను సెటప్ చేసే అంశం ప్రత్యేక కథనానికి అర్హమైనది అని నేను తప్పక చెప్పాలి. మేము మంచి ఫలితాన్ని సాధించడానికి ముందు మేము చాలా సమయం ప్రయోగాలు మరియు పరిశోధనలు చేసాము.

PA-RISC సర్వర్‌ల నుండి x86కి మారుతున్నప్పుడు, మేము ఆచరణాత్మకంగా సిస్టమ్ కోడ్‌ను ఎక్కువగా మార్చాల్సిన అవసరం లేదు, మేము దానిని స్వీకరించి, మళ్లీ కాన్ఫిగర్ చేసాము. అదే సమయంలో, మేము అనేక దోషాలను పరిష్కరించాము. ఉదాహరణకు, PA RISC అనేది బిగ్ ఎండియన్ సిస్టమ్ మరియు x86 ఒక లిటిల్ ఎండియన్ సిస్టమ్ అనే వాస్తవం యొక్క పరిణామాలు త్వరగా బయటపడ్డాయి: ఉదాహరణకు, డేటా తప్పుగా చదవబడింది. గమ్మత్తైన బగ్ ఏమిటంటే PA RISC ఉపయోగిస్తుంది స్థిరంగా స్థిరంగా (వరుసగా స్థిరంగా ఉంటుంది) మెమరీ యాక్సెస్, అయితే x86 రీడ్ ఆపరేషన్‌లను రీఆర్డర్ చేయగలదు, కాబట్టి ఒక ప్లాట్‌ఫారమ్‌లో ఖచ్చితంగా చెల్లుబాటు అయ్యే కోడ్ మరొక ప్లాట్‌ఫారమ్‌లో విచ్ఛిన్నమైంది.

x86కి మారిన తర్వాత, పనితీరు దాదాపు మూడు రెట్లు పెరిగింది, సగటు లావాదేవీ ప్రాసెసింగ్ సమయం 60 μsకి తగ్గింది.

సిస్టమ్ ఆర్కిటెక్చర్‌లో ఎలాంటి కీలక మార్పులు చేశారో ఇప్పుడు నిశితంగా పరిశీలిద్దాం.

హాట్ రిజర్వ్ ఇతిహాసం

కమోడిటీ సర్వర్‌లకు మారినప్పుడు, అవి తక్కువ విశ్వసనీయతతో ఉన్నాయని మాకు తెలుసు. అందువల్ల, కొత్త నిర్మాణాన్ని సృష్టించేటప్పుడు, ఒకటి లేదా అంతకంటే ఎక్కువ నోడ్‌లు విఫలమయ్యే అవకాశం ఉందని మేము ముందుగా ఊహించాము. అందువల్ల, చాలా త్వరగా బ్యాకప్ మెషీన్‌లకు మారగల హాట్ స్టాండ్‌బై సిస్టమ్ అవసరం.

అదనంగా, ఇతర అవసరాలు ఉన్నాయి:

• ఎట్టి పరిస్థితుల్లోనూ మీరు ప్రాసెస్ చేయబడిన లావాదేవీలను కోల్పోకూడదు.
• వ్యవస్థ మన మౌలిక సదుపాయాలకు ఖచ్చితంగా పారదర్శకంగా ఉండాలి.
• ఖాతాదారులు పడిపోయిన కనెక్షన్‌లను చూడకూడదు.
• రిజర్వేషన్లు గణనీయమైన ఆలస్యాన్ని పరిచయం చేయకూడదు ఎందుకంటే ఇది మార్పిడికి కీలకమైన అంశం.

హాట్ స్టాండ్‌బై సిస్టమ్‌ను సృష్టించేటప్పుడు, మేము అలాంటి దృశ్యాలను డబుల్ వైఫల్యాలుగా పరిగణించలేదు (ఉదాహరణకు, ఒక సర్వర్‌లోని నెట్‌వర్క్ పనిచేయడం ఆగిపోయింది మరియు ప్రధాన సర్వర్ స్తంభించిపోయింది); సాఫ్ట్‌వేర్‌లో లోపాల సంభావ్యతను పరిగణించలేదు ఎందుకంటే అవి పరీక్ష సమయంలో గుర్తించబడతాయి; మరియు హార్డ్‌వేర్ యొక్క తప్పు ఆపరేషన్‌ను పరిగణించలేదు.

ఫలితంగా, మేము ఈ క్రింది పథకానికి వచ్చాము:

• ప్రధాన సర్వర్ నేరుగా గేట్‌వే సర్వర్‌లతో పరస్పర చర్య చేసింది.
• ప్రధాన సర్వర్‌లో స్వీకరించిన అన్ని లావాదేవీలు ప్రత్యేక ఛానెల్ ద్వారా బ్యాకప్ సర్వర్‌కు తక్షణమే పునరావృతమవుతాయి. ఏవైనా సమస్యలు తలెత్తితే మార్పిడిని మధ్యవర్తి (గవర్నర్) సమన్వయం చేశారు.

  

• ప్రధాన సర్వర్ ప్రతి లావాదేవీని ప్రాసెస్ చేస్తుంది మరియు బ్యాకప్ సర్వర్ నుండి నిర్ధారణ కోసం వేచి ఉంది. జాప్యాన్ని కనిష్టంగా ఉంచడానికి, మేము బ్యాకప్ సర్వర్‌లో లావాదేవీ పూర్తయ్యే వరకు వేచి ఉండకుండా నివారించాము. ఒక లావాదేవీ నెట్‌వర్క్‌లో ప్రయాణించడానికి పట్టే సమయం అమలు సమయంతో పోల్చదగినది కాబట్టి, అదనపు జాప్యం జోడించబడలేదు.
• మేము మునుపటి లావాదేవీకి సంబంధించిన ప్రధాన మరియు బ్యాకప్ సర్వర్‌ల ప్రాసెసింగ్ స్థితిని మాత్రమే తనిఖీ చేయగలము మరియు ప్రస్తుత లావాదేవీ యొక్క ప్రాసెసింగ్ స్థితి తెలియదు. మేము ఇప్పటికీ సింగిల్-థ్రెడ్ ప్రాసెస్‌లను ఉపయోగిస్తున్నందున, బ్యాకప్ నుండి ప్రతిస్పందన కోసం వేచి ఉండటం వలన మొత్తం ప్రాసెసింగ్ ఫ్లో మందగిస్తుంది, కాబట్టి మేము సహేతుకమైన రాజీని చేసాము: మేము మునుపటి లావాదేవీ ఫలితాన్ని తనిఖీ చేసాము.

పథకం క్రింది విధంగా పనిచేసింది.

ప్రధాన సర్వర్ ప్రతిస్పందించడం ఆపివేసిందని అనుకుందాం, కానీ గేట్‌వేలు కమ్యూనికేట్ చేస్తూనే ఉన్నాయి. బ్యాకప్ సర్వర్‌లో గడువు ముగిసింది, అది గవర్నర్‌ను సంప్రదిస్తుంది, అతను ప్రధాన సర్వర్ పాత్రను కేటాయిస్తారు మరియు అన్ని గేట్‌వేలు కొత్త ప్రధాన సర్వర్‌కు మారతాయి.

ప్రధాన సర్వర్ ఆన్‌లైన్‌కు తిరిగి వచ్చినట్లయితే, ఇది అంతర్గత సమయం ముగియడాన్ని కూడా ప్రేరేపిస్తుంది, ఎందుకంటే నిర్దిష్ట సమయం వరకు గేట్‌వే నుండి సర్వర్‌కు కాల్‌లు లేవు. అప్పుడు అతను కూడా గవర్నర్‌ను ఆశ్రయించాడు మరియు అతను అతన్ని పథకం నుండి మినహాయించాడు. ఫలితంగా, ట్రేడింగ్ వ్యవధి ముగిసే వరకు మార్పిడి ఒక సర్వర్‌తో పనిచేస్తుంది. సర్వర్ వైఫల్యం సంభావ్యత చాలా తక్కువగా ఉన్నందున, ఈ పథకం చాలా ఆమోదయోగ్యమైనదిగా పరిగణించబడింది; ఇది సంక్లిష్ట తర్కాన్ని కలిగి ఉండదు మరియు పరీక్షించడం సులభం.

కొనసాగించాలి.

మూలం: www.habr.com