పంపిణీ చేయబడిన అప్లికేషన్ల బిల్డింగ్ బ్లాక్స్. రెండవ ఉజ్జాయింపు

ప్రకటన

సహోద్యోగులారా, వేసవి మధ్యలో నేను క్యూయింగ్ సిస్టమ్‌ల రూపకల్పనపై మరొక కథనాలను విడుదల చేయాలని ప్లాన్ చేస్తున్నాను: “VTrade ప్రయోగం” - ట్రేడింగ్ సిస్టమ్‌ల కోసం ఒక ఫ్రేమ్‌వర్క్‌ను వ్రాసే ప్రయత్నం. ఈ సిరీస్ మార్పిడి, వేలం మరియు దుకాణాన్ని నిర్మించే సిద్ధాంతం మరియు అభ్యాసాన్ని పరిశీలిస్తుంది. వ్యాసం ముగింపులో, మీకు అత్యంత ఆసక్తి ఉన్న అంశాలకు ఓటు వేయమని నేను మిమ్మల్ని ఆహ్వానిస్తున్నాను.

Erlang/Elixirలో పంపిణీ చేయబడిన రియాక్టివ్ అప్లికేషన్‌లపై సిరీస్‌లో ఇది చివరి కథనం. IN మొదటి వ్యాసం మీరు రియాక్టివ్ ఆర్కిటెక్చర్ యొక్క సైద్ధాంతిక పునాదులను కనుగొనవచ్చు. రెండవ వ్యాసం అటువంటి వ్యవస్థలను నిర్మించడానికి ప్రాథమిక నమూనాలు మరియు యంత్రాంగాలను వివరిస్తుంది.

ఈ రోజు మనం కోడ్ బేస్ మరియు ప్రాజెక్ట్‌ల అభివృద్ధి సమస్యలను లేవనెత్తుతాము.

సేవల సంస్థ

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

మేము తప్పు-తట్టుకునే పంపిణీ సేవను అమలు చేయవలసి వచ్చినప్పుడు పరిస్థితి మరింత క్లిష్టంగా మారుతుంది. వినియోగదారుల అవసరాలు మారాయని ఊహించుదాం:

1. ఇప్పుడు సేవ 5 క్లస్టర్ నోడ్‌లలో అభ్యర్థనలను ప్రాసెస్ చేయాలి,
2. నేపథ్య ప్రాసెసింగ్ పనులను చేయగలరు,
3. మరియు ప్రొఫైల్ అప్‌డేట్‌ల కోసం చందా జాబితాలను డైనమిక్‌గా నిర్వహించగలుగుతారు.

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

వినియోగదారుల సేవ యొక్క అధికారిక వివరణ మరింత క్లిష్టంగా మారింది. ప్రోగ్రామర్ దృక్కోణంలో, సందేశాన్ని ఉపయోగించడం వల్ల మార్పులు తక్కువగా ఉంటాయి. మొదటి అవసరాన్ని తీర్చడానికి, మేము req-resp ఎక్స్ఛేంజ్ పాయింట్ వద్ద బ్యాలెన్సింగ్‌ను కాన్ఫిగర్ చేయాలి.

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

పాయింట్ 3కి పబ్-సబ్ టెంప్లేట్ పొడిగింపు అవసరం. మరియు అమలు కోసం, పబ్-సబ్ ఎక్స్ఛేంజ్ పాయింట్‌ని సృష్టించిన తర్వాత, మేము మా సేవలో ఈ పాయింట్ యొక్క కంట్రోలర్‌ను అదనంగా ప్రారంభించాలి. అందువల్ల, మేము సబ్‌స్క్రిప్షన్‌లను ప్రాసెస్ చేయడం మరియు మెసేజింగ్ లేయర్ నుండి అన్‌సబ్‌స్క్రైబ్ చేయడం కోసం లాజిక్‌ను వినియోగదారుల అమలులోకి తరలిస్తున్నట్లుగా ఉంటుంది.

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

నాయకుని ఎంపిక

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

కేంద్రీకరణకు అవకాశం లేని వ్యవస్థలలో, పాక్సోస్ లేదా తెప్ప వంటి సార్వత్రిక మరియు ఏకాభిప్రాయం ఆధారిత అల్గారిథమ్‌లు ఉపయోగించబడతాయి.
మెసేజింగ్ అనేది బ్రోకర్ మరియు కేంద్ర అంశం కాబట్టి, అన్ని సర్వీస్ కంట్రోలర్‌ల గురించి - అభ్యర్థుల లీడర్‌ల గురించి దీనికి తెలుసు. సందేశం ఓటు వేయకుండానే నాయకుడిని నియమించవచ్చు.

మార్పిడి పాయింట్‌ను ప్రారంభించి, కనెక్ట్ చేసిన తర్వాత, అన్ని సేవలు సిస్టమ్ సందేశాన్ని అందుకుంటాయి #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. ఉంటే LeaderPid ఏకీభవిస్తుంది pid ప్రస్తుత ప్రక్రియ, ఇది నాయకుడిగా నియమించబడింది మరియు జాబితా Servers అన్ని నోడ్‌లు మరియు వాటి పారామితులను కలిగి ఉంటుంది.
ప్రస్తుతానికి కొత్తది కనిపిస్తుంది మరియు పని చేసే క్లస్టర్ నోడ్ డిస్‌కనెక్ట్ చేయబడింది, అన్ని సర్వీస్ కంట్రోలర్‌లు అందుకుంటారు #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} వరుసగా.

ఈ విధంగా, అన్ని భాగాలు అన్ని మార్పుల గురించి తెలుసుకుంటాయి మరియు క్లస్టర్ ఏ సమయంలోనైనా ఒక నాయకుడిని కలిగి ఉంటుందని హామీ ఇవ్వబడుతుంది.

మధ్యవర్తులు

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

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

• క్లయింట్ ప్లాట్‌ఫారమ్‌తో కనెక్షన్‌లను ఏర్పరుస్తుంది. ట్రాఫిక్‌ను నిలిపివేసే సర్వర్ వైపున, ఈ కనెక్షన్‌కి సేవ చేయడానికి ఒక ప్రక్రియ ప్రారంభించబడింది.
• సేవా ప్రక్రియ సందర్భంలో, అప్‌డేట్‌లకు అధికారం మరియు సభ్యత్వం ఏర్పడతాయి. ప్రక్రియ అంశాల కోసం సబ్‌స్క్రైబ్ పద్ధతిని పిలుస్తుంది.
• కెర్నల్‌లో ఈవెంట్‌ని రూపొందించిన తర్వాత, అది కనెక్షన్‌లకు సర్వీసింగ్ చేసే ప్రక్రియలకు డెలివరీ చేయబడుతుంది.

"వార్తలు" అంశానికి 50000 మంది సబ్‌స్క్రైబర్‌లను కలిగి ఉన్నారని ఊహించుకుందాం. సబ్‌స్క్రైబర్‌లు 5 సర్వర్‌లలో సమానంగా పంపిణీ చేయబడతారు. ఫలితంగా, ఎక్స్ఛేంజ్ పాయింట్ వద్దకు వచ్చే ప్రతి అప్‌డేట్ 50000 సార్లు పునరావృతమవుతుంది: ప్రతి సర్వర్‌లో 10000 సార్లు, దానిలోని చందాదారుల సంఖ్య ప్రకారం. చాలా ప్రభావవంతమైన పథకం కాదు, సరియైనదా?
పరిస్థితిని మెరుగుపరచడానికి, ఎక్స్ఛేంజ్ పాయింట్ వలె అదే పేరుతో ఉన్న ప్రాక్సీని పరిచయం చేద్దాం. గ్లోబల్ నేమ్ రిజిస్ట్రార్ తప్పనిసరిగా దగ్గరి ప్రక్రియను పేరు ద్వారా తిరిగి ఇవ్వగలగాలి, ఇది ముఖ్యమైనది.

యాక్సెస్ లేయర్ సర్వర్‌లలో ఈ ప్రాక్సీని ప్రారంభిద్దాం మరియు వెబ్‌సాకెట్ apiని అందించే మా అన్ని ప్రక్రియలు దీనికి సభ్యత్వాన్ని పొందుతాయి మరియు కెర్నల్‌లోని అసలు పబ్-సబ్ ఎక్స్ఛేంజ్ పాయింట్‌కి కాదు. ప్రాక్సీ ఒక ప్రత్యేకమైన సబ్‌స్క్రిప్షన్ విషయంలో మాత్రమే కోర్‌కి సబ్‌స్క్రయిబ్ చేస్తుంది మరియు ఇన్‌కమింగ్ మెసేజ్‌ని దాని సబ్‌స్క్రైబర్‌లందరికీ రిప్లికేట్ చేస్తుంది.
ఫలితంగా, కెర్నల్ మరియు యాక్సెస్ సర్వర్‌ల మధ్య 5కి బదులుగా 50000 సందేశాలు పంపబడతాయి.

రూటింగ్ మరియు బ్యాలెన్సింగ్

Req-Resp

ప్రస్తుత సందేశ అమలులో, 7 అభ్యర్థన పంపిణీ వ్యూహాలు ఉన్నాయి:

• default. అభ్యర్థన అన్ని కంట్రోలర్‌లకు పంపబడుతుంది.
• round-robin. అభ్యర్థనలు లెక్కించబడతాయి మరియు కంట్రోలర్‌ల మధ్య చక్రీయంగా పంపిణీ చేయబడతాయి.
• consensus. సేవను అందించే కంట్రోలర్లు నాయకులు మరియు బానిసలుగా విభజించబడ్డారు. అభ్యర్థనలు నాయకుడికి మాత్రమే పంపబడతాయి.
• consensus & round-robin. సమూహానికి ఒక నాయకుడు ఉన్నారు, కానీ అభ్యర్థనలు సభ్యులందరికీ పంపిణీ చేయబడతాయి.
• sticky. హాష్ ఫంక్షన్ లెక్కించబడుతుంది మరియు నిర్దిష్ట హ్యాండ్లర్‌కు కేటాయించబడుతుంది. ఈ సంతకంతో తదుపరి అభ్యర్థనలు అదే హ్యాండ్లర్‌కు వెళ్తాయి.
• sticky-fun. ఎక్స్ఛేంజ్ పాయింట్‌ను ప్రారంభించినప్పుడు, కోసం హాష్ లెక్కింపు ఫంక్షన్ sticky బ్యాలెన్సింగ్.
• fun. స్టిక్కీ-ఫన్ లాగానే, మీరు మాత్రమే దీన్ని అదనంగా దారి మళ్లించగలరు, తిరస్కరించగలరు లేదా ముందుగా ప్రాసెస్ చేయగలరు.

మార్పిడి పాయింట్ ప్రారంభించబడినప్పుడు పంపిణీ వ్యూహం సెట్ చేయబడుతుంది.

బ్యాలెన్సింగ్‌తో పాటు, మెసేజింగ్ ఎంటిటీలను ట్యాగ్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. సిస్టమ్‌లోని ట్యాగ్‌ల రకాలను చూద్దాం:

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

పబ్-సబ్

పబ్-సబ్ కోసం ప్రతిదీ కొద్దిగా సులభం. మేము సందేశాలను ప్రచురించే మార్పిడి పాయింట్‌ని కలిగి ఉన్నాము. ఎక్స్ఛేంజ్ పాయింట్ తమకు అవసరమైన రూటింగ్ కీలను సబ్‌స్క్రైబర్ చేసిన సబ్‌స్క్రైబర్‌ల మధ్య సందేశాలను పంపిణీ చేస్తుంది (ఇది టాపిక్‌లకు సారూప్యమని మేము చెప్పగలం).

స్కేలబిలిటీ మరియు తప్పు సహనం

సిస్టమ్ యొక్క స్కేలబిలిటీ మొత్తం వ్యవస్థ యొక్క పొరలు మరియు భాగాల స్కేలబిలిటీ స్థాయిపై ఆధారపడి ఉంటుంది:

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

ప్రాజెక్ట్ యొక్క విజయం తరచుగా స్కేలింగ్ యొక్క సరళత మరియు వేగంపై ఆధారపడి ఉంటుంది. అప్లికేషన్‌తో పాటు దాని ప్రస్తుత వెర్షన్‌లో మెసేజింగ్ పెరుగుతుంది. మనకు 50-60 యంత్రాల క్లస్టర్ లేకపోయినా, మేము ఫెడరేషన్‌ను ఆశ్రయించవచ్చు. దురదృష్టవశాత్తు, సమాఖ్య అంశం ఈ వ్యాసం యొక్క పరిధికి మించినది.

రిజర్వేషన్

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

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

ఉత్పాదకత

కనీసం rabbitmq పనితీరును మరియు మా అనుకూల సందేశాన్ని పోల్చడానికి ప్రయత్నిద్దాం.
నాకు దొరికింది అధికారిక ఫలితాలు ఓపెన్‌స్టాక్ బృందం నుండి rabbitmq పరీక్ష.

పేరా 6.14.1.2.1.2.2 లో. అసలు పత్రం RPC CAST ఫలితాన్ని చూపుతుంది:

మేము ముందుగానే OS కెర్నల్ లేదా erlang VMకి అదనపు సెట్టింగ్‌లు ఏవీ చేయము. పరీక్ష కోసం షరతులు:

• erl ఎంపికలు: +A1 +sbtu.
• ఒకే ఎర్లాంగ్ నోడ్‌లోని పరీక్ష మొబైల్ వెర్షన్‌లో పాత i7తో ల్యాప్‌టాప్‌లో అమలు చేయబడుతుంది.
• 10G నెట్‌వర్క్ ఉన్న సర్వర్‌లలో క్లస్టర్ పరీక్షలు నిర్వహించబడతాయి.
• కోడ్ డాకర్ కంటైనర్లలో నడుస్తుంది. NAT మోడ్‌లో నెట్‌వర్క్.

పరీక్ష కోడ్:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

దృశ్యం 1: పరీక్ష పాత i7 మొబైల్ వెర్షన్‌తో ల్యాప్‌టాప్‌లో అమలు చేయబడుతుంది. పరీక్ష, సందేశం మరియు సేవ ఒక డాకర్ కంటైనర్‌లో ఒక నోడ్‌లో అమలు చేయబడతాయి:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

దృశ్యం 2: డాకర్ (NAT) కింద వేర్వేరు యంత్రాలపై 3 నోడ్‌లు రన్ అవుతాయి.

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

అన్ని సందర్భాల్లో, CPU వినియోగం 250% మించలేదు

ఫలితాలు

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

ఫోటో @చటర్‌స్నాప్

నమోదు చేసుకున్న వినియోగదారులు మాత్రమే సర్వేలో పాల్గొనగలరు. సైన్ ఇన్ చేయండిదయచేసి.

VTrade ప్రయోగం సిరీస్‌లో భాగంగా నేను ఏ అంశాలను మరింత వివరంగా కవర్ చేయాలి?

• సిద్ధాంతం: మార్కెట్‌లు, ఆర్డర్‌లు మరియు వాటి సమయం: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC

• ఆర్డర్ల పుస్తకం. సమూహాలతో పుస్తకాన్ని అమలు చేసే సిద్ధాంతం మరియు అభ్యాసం

• ట్రేడింగ్ యొక్క విజువలైజేషన్: టిక్‌లు, బార్‌లు, రిజల్యూషన్‌లు. ఎలా నిల్వ చేయాలి మరియు ఎలా జిగురు చేయాలి

• బ్యాక్ ఆఫీస్. ప్రణాళిక మరియు అభివృద్ధి. ఉద్యోగి పర్యవేక్షణ మరియు సంఘటన విచారణ

• API. ఏ ఇంటర్‌ఫేస్‌లు అవసరమో మరియు వాటిని ఎలా అమలు చేయాలో తెలుసుకుందాం

• సమాచార నిల్వ: PostgreSQL, టైమ్‌స్కేల్, ట్రేడింగ్ సిస్టమ్‌లలో టరాన్టూల్

• ట్రేడింగ్ సిస్టమ్స్‌లో రియాక్టివిటీ

• ఇతర. నేను వ్యాఖ్యలలో వ్రాస్తాను

6 మంది వినియోగదారులు ఓటు వేశారు. 4 వినియోగదారులు దూరంగా ఉన్నారు.

మూలం: www.habr.com