హే హబ్ర్!

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

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

క్షితిజసమాంతర స్కేలింగ్

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

ఉదాహరణకు, నేను వియుక్త క్లౌడ్ ఫైల్ నిల్వను తీసుకుంటాను, అంటే, OwnCloud, OneDrive మొదలైన వాటి యొక్క కొంత అనలాగ్.

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

విధానాల మధ్య వ్యత్యాసం: నిలువు స్కేలింగ్‌లో, నోడ్‌ల శక్తిని పెంచడానికి మేము సిద్ధంగా ఉన్నాము మరియు క్షితిజ సమాంతర స్కేలింగ్‌లో, లోడ్‌ను పంపిణీ చేయడానికి కొత్త నోడ్‌లను జోడించడానికి మేము సిద్ధంగా ఉన్నాము.

CQRS

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

ఈ విధానం యొక్క మొదటి బోనస్ సుదీర్ఘ అభ్యర్థనను అమలు చేస్తున్నప్పుడు కనెక్షన్‌ను (పదం యొక్క విస్తృత అర్థంలో) విచ్ఛిన్నం చేసే సామర్థ్యం. ఉదాహరణకు, ఎక్కువ లేదా తక్కువ ప్రామాణిక క్రమాన్ని తీసుకుందాం:

1. క్లయింట్ సర్వర్‌కు అభ్యర్థనను పంపారు.
2. సర్వర్ సుదీర్ఘ ప్రాసెసింగ్ సమయాన్ని ప్రారంభించింది.
3. సర్వర్ ఫలితంతో క్లయింట్‌కు ప్రతిస్పందించింది.

పాయింట్ 2లో కనెక్షన్ విచ్ఛిన్నమైందని ఊహించుదాం (లేదా నెట్‌వర్క్ మళ్లీ కనెక్ట్ చేయబడింది, లేదా వినియోగదారు మరొక పేజీకి వెళ్లి, కనెక్షన్‌ను విచ్ఛిన్నం చేయడం). ఈ సందర్భంలో, సరిగ్గా ప్రాసెస్ చేయబడిన దాని గురించి సమాచారంతో వినియోగదారుకు ప్రతిస్పందనను పంపడం సర్వర్‌కు కష్టమవుతుంది. CQRS ఉపయోగించి, క్రమం కొద్దిగా భిన్నంగా ఉంటుంది:

1. క్లయింట్ నవీకరణలకు సభ్యత్వాన్ని పొందారు.
2. క్లయింట్ సర్వర్‌కు అభ్యర్థనను పంపారు.
3. సర్వర్ "అభ్యర్థన ఆమోదించబడింది" అని ప్రతిస్పందించింది.
4. "1" పాయింట్ నుండి ఛానెల్ ద్వారా సర్వర్ ఫలితంతో ప్రతిస్పందించింది.

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

ఆసక్తికరంగా, ఇన్‌కమింగ్ సందేశాలను ప్రాసెస్ చేసే కోడ్ క్లయింట్ ద్వారా ప్రభావితమైన ఈవెంట్‌లకు మరియు ఇతర క్లయింట్‌లతో సహా ఇతర ఈవెంట్‌లకు ఒకే విధంగా ఉంటుంది (100% కాదు).

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

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

ఈవెంట్ సోర్సింగ్

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

ఇక్కడ నుండి మేము ఒక ముఖ్యమైన వాస్తవాన్ని పొందుతాము - వేగంగా పంపిణీ చేయబడిన వ్యవస్థ సమకాలీకరించబడదు, ఎందుకంటే మేము పనితీరును తగ్గిస్తాము. మరోవైపు, మనకు తరచుగా భాగాల మధ్య ఒక నిర్దిష్ట స్థిరత్వం అవసరం. మరియు దీని కోసం మీరు విధానాన్ని ఉపయోగించవచ్చు చివరికి స్థిరత్వం, చివరి అప్‌డేట్ (“చివరికి”) తర్వాత కొంత సమయం వరకు డేటా మార్పులు లేనట్లయితే, అన్ని ప్రశ్నలు చివరిగా నవీకరించబడిన విలువను అందజేస్తాయని హామీ ఇవ్వబడుతుంది.

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

అయితే, అసలు పనికి తిరిగి వద్దాం. వ్యవస్థలో కొంత భాగాన్ని నిర్మించగలిగితే చివరికి స్థిరత్వం, అప్పుడు మనం క్రింది రేఖాచిత్రాన్ని నిర్మించవచ్చు.

ఈ విధానం యొక్క ముఖ్యమైన లక్షణాలు:

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

మేము ఆన్‌లైన్ ఫైల్ నిల్వ విషయంలో పరిశీలిస్తున్నామని నేను మీకు గుర్తు చేస్తున్నాను. ఈ సందర్భంలో, సిస్టమ్ ఇలా కనిపిస్తుంది:

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

మరియు ఇద్దరు వినియోగదారుల కోసం రేఖాచిత్రం ఇలా కనిపిస్తుంది (వేర్వేరు వినియోగదారుల కోసం ఉద్దేశించిన సేవలు వేర్వేరు రంగులలో సూచించబడతాయి):

అటువంటి కలయిక నుండి బోనస్లు:

• సమాచార ప్రాసెసింగ్ సేవలు వేరు చేయబడ్డాయి. క్యూలు కూడా వేరు. మేము సిస్టమ్ నిర్గమాంశను పెంచాల్సిన అవసరం ఉంటే, మేము మరిన్ని సర్వర్‌లలో మరిన్ని సేవలను ప్రారంభించాలి.
• మేము వినియోగదారు నుండి సమాచారాన్ని స్వీకరించినప్పుడు, డేటా పూర్తిగా సేవ్ చేయబడే వరకు మేము వేచి ఉండాల్సిన అవసరం లేదు. దీనికి విరుద్ధంగా, మనం “సరే” అని సమాధానం ఇవ్వాలి మరియు క్రమంగా పని చేయడం ప్రారంభించాలి. అదే సమయంలో, క్యూ శిఖరాలను సున్నితంగా చేస్తుంది, ఎందుకంటే కొత్త వస్తువును జోడించడం త్వరగా జరుగుతుంది మరియు వినియోగదారు మొత్తం చక్రం ద్వారా పూర్తి పాస్ కోసం వేచి ఉండాల్సిన అవసరం లేదు.
• ఉదాహరణగా, నేను ఒకేలా ఉండే ఫైల్‌లను విలీనం చేయడానికి ప్రయత్నించే డీప్లికేషన్ సర్వీస్‌ని జోడించాను. ఇది 1% కేసులలో చాలా కాలం పాటు పని చేస్తే, క్లయింట్ దానిని గుర్తించలేడు (పైన చూడండి), ఇది పెద్ద ప్లస్, ఎందుకంటే మేము ఇకపై XNUMX% వేగం మరియు విశ్వసనీయంగా ఉండాల్సిన అవసరం లేదు.

అయితే, ప్రతికూలతలు వెంటనే కనిపిస్తాయి:

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

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

ఫలితంగా:

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

షార్డింగ్

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

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

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

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

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

ఈ విధంగా, ఫైల్‌ల కోసం ఆన్‌లైన్ నిల్వ గురించి మా ఉదాహరణను కొనసాగిస్తూ, అటువంటి నిర్మాణం ఇప్పటికే మాకు అనేక బోనస్‌లను ఇస్తుంది:

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

స్టాటిక్ కంటెంట్ హోస్టింగ్

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

స్టాటిక్ కంటెంట్ యొక్క సరళమైన మరియు అత్యంత ప్రామాణికమైన ఉదాహరణ వెబ్‌సైట్ కోసం స్క్రిప్ట్‌లు మరియు చిత్రాల సమితి. ప్రతిదీ వారితో సులభం - వారు ముందుగానే పిలుస్తారు, అప్పుడు ఆర్కైవ్ CDN సర్వర్‌లకు అప్‌లోడ్ చేయబడుతుంది, అక్కడ నుండి అవి తుది వినియోగదారులకు పంపిణీ చేయబడతాయి.

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

• సర్వర్ డౌన్‌లోడ్ URLను అందిస్తుంది. ఇది ఫైల్_ఐడి + కీ ఫారమ్ కావచ్చు, ఇక్కడ కీ అనేది మినీ-డిజిటల్ సంతకం, ఇది తదుపరి XNUMX గంటల వరకు వనరును యాక్సెస్ చేసే హక్కును ఇస్తుంది.
• ఫైల్ క్రింది ఎంపికలతో సాధారణ nginx ద్వారా పంపిణీ చేయబడుతుంది:
  • కంటెంట్ కాషింగ్. ఈ సేవ ప్రత్యేక సర్వర్‌లో ఉన్నందున, డిస్క్‌లో అన్ని తాజా డౌన్‌లోడ్ చేసిన ఫైల్‌లను నిల్వ చేయగల సామర్థ్యంతో మేము భవిష్యత్తు కోసం రిజర్వ్‌గా ఉంచుకున్నాము.
  • కనెక్షన్ సృష్టించే సమయంలో కీని తనిఖీ చేస్తోంది
• ఐచ్ఛికం: స్ట్రీమింగ్ కంటెంట్ ప్రాసెసింగ్. ఉదాహరణకు, మేము సేవలోని అన్ని ఫైల్‌లను కుదించినట్లయితే, మేము ఈ మాడ్యూల్‌లో నేరుగా అన్‌జిప్ చేయవచ్చు. పర్యవసానంగా: IO ఆపరేషన్‌లు ఎక్కడైతే జరుగుతాయి. జావాలోని ఆర్కైవర్ చాలా అదనపు మెమరీని సులభంగా కేటాయిస్తుంది, అయితే వ్యాపార లాజిక్‌తో సేవను రస్ట్/C++ షరతులతో తిరిగి వ్రాయడం కూడా పనికిరానిది కావచ్చు. మా విషయంలో, విభిన్న ప్రక్రియలు (లేదా సేవలు కూడా) ఉపయోగించబడతాయి మరియు అందువల్ల మేము వ్యాపార తర్కం మరియు IO కార్యకలాపాలను చాలా ప్రభావవంతంగా వేరు చేయవచ్చు.

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

మరొక ఉదాహరణగా (బలోపేతం కోసం): మీరు Jenkins/TeamCityతో కలిసి పనిచేసినట్లయితే, రెండు పరిష్కారాలు జావాలో వ్రాయబడిందని మీకు తెలుసు. రెండూ బిల్డ్ ఆర్కెస్ట్రేషన్ మరియు కంటెంట్ మేనేజ్‌మెంట్ రెండింటినీ నిర్వహించే జావా ప్రక్రియ. ప్రత్యేకించి, వారిద్దరికీ "సర్వర్ నుండి ఫైల్/ఫోల్డర్‌ను బదిలీ చేయడం" వంటి పనులు ఉన్నాయి. ఉదాహరణగా: కళాఖండాలను జారీ చేయడం, సోర్స్ కోడ్‌ను బదిలీ చేయడం (ఏజెంట్ రిపోజిటరీ నుండి నేరుగా కోడ్‌ను డౌన్‌లోడ్ చేయనప్పుడు, సర్వర్ అతని కోసం దీన్ని చేస్తుంది), లాగ్‌లకు ప్రాప్యత. ఈ పనులన్నీ వాటి IO లోడ్‌లో విభిన్నంగా ఉంటాయి. అంటే, సంక్లిష్ట వ్యాపార లాజిక్‌కు బాధ్యత వహించే సర్వర్ అదే సమయంలో పెద్ద మొత్తంలో డేటాను సమర్థవంతంగా నెట్టగలగాలి. మరియు చాలా ఆసక్తికరమైన విషయం ఏమిటంటే, అటువంటి ఆపరేషన్ సరిగ్గా అదే పథకం ప్రకారం అదే nginxకి అప్పగించబడుతుంది (డేటా కీని అభ్యర్థనకు జోడించడం మినహా).

అయినప్పటికీ, మేము మా సిస్టమ్‌కి తిరిగి వస్తే, మనకు ఇలాంటి రేఖాచిత్రం వస్తుంది:

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

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

తీర్మానం

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

అయితే, ముఖ్యంగా, ఈ నమూనాలన్నీ ఆధునిక అనువర్తనాల్లో (అవి సముచితంగా ఉంటే, వాస్తవానికి) వర్తింపజేయడం చాలా సులభం. క్లౌడ్‌లు తక్షణమే షార్డింగ్ మరియు క్షితిజ సమాంతర స్కేలింగ్‌ను అందిస్తాయి, ఇది వివిధ డేటా సెంటర్‌లలో వేర్వేరు డెడికేటెడ్ సర్వర్‌లను మీరే ఆర్డర్ చేయడం కంటే చాలా సులభం. RX వంటి లైబ్రరీల అభివృద్ధి కారణంగా మాత్రమే CQRS చాలా సులభం అయింది. సుమారు 10 సంవత్సరాల క్రితం, అరుదైన వెబ్‌సైట్ దీనికి మద్దతు ఇవ్వగలదు. Apache Kafkaతో రెడీమేడ్ కంటైనర్‌ల కారణంగా ఈవెంట్ సోర్సింగ్‌ని సెటప్ చేయడం కూడా చాలా సులభం. 10 సంవత్సరాల క్రితం ఇది ఒక ఆవిష్కరణగా ఉండేది, ఇప్పుడు ఇది సర్వసాధారణం. ఇది స్టాటిక్ కంటెంట్ హోస్టింగ్‌తో సమానంగా ఉంటుంది: మరింత సౌకర్యవంతమైన సాంకేతికతల కారణంగా (వివరణాత్మక డాక్యుమెంటేషన్ మరియు సమాధానాల యొక్క పెద్ద డేటాబేస్ ఉండటంతో సహా), ఈ విధానం మరింత సరళంగా మారింది.

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

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

మూలం: www.habr.com