అప్లికేషన్‌లో ACIDని ఎలా అమలు చేయాలి: సాధన

8.1 లావాదేవీ IDలు

ఇది XID లేదా TxIDగా నియమించబడింది (తేడా ఉంటే, నాకు చెప్పండి). టైమ్‌స్టాంప్‌లను TxIDగా ఉపయోగించవచ్చు, మేము అన్ని చర్యలను కొంత సమయానికి పునరుద్ధరించాలనుకుంటే ఇది చేతుల్లోకి ప్లే అవుతుంది. టైమ్‌స్టాంప్ తగినంత గ్రాన్యులర్‌గా లేకుంటే సమస్య తలెత్తవచ్చు - అప్పుడు లావాదేవీలు ఒకే IDని పొందవచ్చు.

అందువల్ల, ప్రత్యేకమైన UUID ఉత్పత్తి IDలను రూపొందించడం అత్యంత విశ్వసనీయ ఎంపిక. పైథాన్‌లో ఇది చాలా సులభం:

>>> import uuid 
>>> str(uuid.uuid4()) 
'f50ec0b7-f960-400d-91f0-c42a6d44e3d0' 
>>> str(uuid.uuid4()) 
'd15bed89-c0a5-4a72-98d9-5507ea7bc0ba' 

లావాదేవీని నిర్వచించే డేటా సెట్‌ను హ్యాష్ చేయడానికి మరియు ఈ హాష్‌ని TxIDగా ఉపయోగించడానికి కూడా ఒక ఎంపిక ఉంది.

8.2 మళ్లీ ప్రయత్నాలు

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

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

import logging
import random
import sys
from tenacity import retry, stop_after_attempt, stop_after_delay, wait_exponential, retry_if_exception_type, before_log

logging.basicConfig(stream=sys.stderr, level=logging.DEBUG)
logger = logging.getLogger(__name__)

@retry(
	stop=(stop_after_delay(10) | stop_after_attempt(5)),
	wait=wait_exponential(multiplier=1, min=4, max=10),
	retry=retry_if_exception_type(IOError),
	before=before_log(logger, logging.DEBUG)
)
def do_something_unreliable():
	if random.randint(0, 10) > 1:
    	raise IOError("Broken sauce, everything is hosed!!!111one")
	else:
    	return "Awesome sauce!"

print(do_something_unreliable.retry.statistics)

> ఒకవేళ, నేను ఇలా చెబుతాను: \@retry(...) అనేది "డెకరేటర్" అని పిలువబడే ఒక ప్రత్యేక పైథాన్ సింటాక్స్. ఇది కేవలం ఒక పునఃప్రయత్నం(...) ఫంక్షన్ మరొక ఫంక్షన్‌ను చుట్టి, అది అమలు చేయడానికి ముందు లేదా తర్వాత ఏదైనా చేస్తుంది.

మేము చూడగలిగినట్లుగా, పునఃప్రయత్నాలను సృజనాత్మకంగా రూపొందించవచ్చు:

• మీరు ప్రయత్నాలను సమయం (10 సెకన్లు) లేదా ప్రయత్నాల సంఖ్య (5) ద్వారా పరిమితం చేయవచ్చు.
• ఘాతాంకం కావచ్చు (అంటే, 2 ** కొంత పెరుగుతున్న సంఖ్య n ). లేదా వేరే ప్రయత్నాల మధ్య సమయాన్ని పెంచడానికి వేరే విధంగా (ఉదాహరణకు, పరిష్కరించబడింది). ఎక్స్‌పోనెన్షియల్ వేరియంట్‌ను "రద్దీ పతనం" అంటారు.
• మీరు కొన్ని రకాల ఎర్రర్‌ల కోసం మాత్రమే మళ్లీ ప్రయత్నించవచ్చు (IOError).
• లాగ్‌లోని కొన్ని ప్రత్యేక ఎంట్రీల ద్వారా మళ్లీ ప్రయత్నించే ప్రయత్నాలను ముందుగా లేదా పూర్తి చేయవచ్చు.

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

8.3 లావాదేవీ ప్రియుల కోసం అధునాతన సాధనాలు

నేను చాలా సాధారణ నిర్వచనాలను మాత్రమే ఇస్తాను, ఎందుకంటే ఈ అంశం ప్రత్యేక పెద్ద వ్యాసానికి అర్హమైనది.

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

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

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

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

సాగా డీబగ్ చేయడం కష్టం, ప్రత్యేకించి అనేక మైక్రోసర్వీస్‌లు ఉన్నప్పుడు. సాగా నమూనా యొక్క మరొక ప్రతికూలత ఏమిటంటే దీనికి రీడ్ ఐసోలేషన్ లేకపోవడం. అంటే, ACIDలో సూచించబడిన లక్షణాలు మనకు ముఖ్యమైనవి అయితే, సాగా మనకు చాలా సరిఅయినది కాదు.

ఈ రెండు పద్ధతుల వివరణ నుండి మనం ఏమి చూస్తాము? పంపిణీ వ్యవస్థలలో, పరమాణు మరియు ఐసోలేషన్ యొక్క బాధ్యత అప్లికేషన్‌పై ఉంటుంది. ACID హామీలను అందించని డేటాబేస్‌లను ఉపయోగిస్తున్నప్పుడు అదే జరుగుతుంది. అంటే, సంఘర్షణ పరిష్కారం, రోల్‌బ్యాక్‌లు, కమిట్‌లు మరియు ఖాళీని ఖాళీ చేయడం వంటి విషయాలు డెవలపర్ భుజాలపై పడతాయి.

8.4 నాకు ACID హామీలు అవసరమైనప్పుడు నాకు ఎలా తెలుస్తుంది?

అధిక సంభావ్యత ఉన్నప్పుడు, నిర్దిష్ట వినియోగదారులు లేదా ప్రక్రియలు ఒకే డేటాపై ఏకకాలంలో పని చేస్తాయి .

సామాన్యమైనందుకు క్షమించండి, కానీ ఒక సాధారణ ఉదాహరణ ఆర్థిక లావాదేవీలు.

లావాదేవీలు నిర్వహించబడే క్రమం ముఖ్యమైనది.

మీ కంపెనీ FunnyYellowChat మెసెంజర్ నుండి FunnyRedChat మెసెంజర్‌కు మారబోతోందని ఊహించండి, ఎందుకంటే FunnyRedChat మిమ్మల్ని gifలను పంపడానికి అనుమతిస్తుంది, కానీ FunnyYellowChat చేయదు. కానీ మీరు కేవలం మెసెంజర్‌ని మాత్రమే మార్చడం లేదు - మీరు మీ కంపెనీకి సంబంధించిన కరస్పాండెన్స్‌ని ఒక మెసెంజర్ నుండి మరొకదానికి మారుస్తున్నారు. ప్రోగ్రామ్‌లు మరియు ప్రాసెస్‌లను ఎక్కడో కేంద్రంగా డాక్యుమెంట్ చేయడంలో మీ ప్రోగ్రామర్లు చాలా బద్ధకంగా ఉన్నారు మరియు బదులుగా వారు మెసెంజర్‌లోని వివిధ ఛానెల్‌లలో ప్రతిదాన్ని ప్రచురించారు కాబట్టి మీరు దీన్ని చేస్తారు. అవును, మరియు మీ విక్రయదారులు అదే స్థలంలో చర్చలు మరియు ఒప్పందాల వివరాలను ప్రచురించారు. సంక్షిప్తంగా, మీ కంపెనీ మొత్తం జీవితం ఉంది, మరియు డాక్యుమెంటేషన్ కోసం మొత్తం విషయాన్ని ఒక సేవకు బదిలీ చేయడానికి ఎవరికీ సమయం లేదు మరియు తక్షణ దూతల కోసం శోధన బాగా పని చేస్తుంది కాబట్టి, మీరు రాళ్లను క్లియర్ చేయడానికి బదులుగా అన్నింటినీ కాపీ చేయడానికి నిర్ణయించుకున్నారు. కొత్త స్థానానికి సందేశాలు. సందేశాల క్రమం ముఖ్యం

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

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

మీరు వినియోగదారుని అందించలేనప్పుడు లేదా పాత డేటాను ప్రాసెస్ చేయలేరు.

మరియు మళ్ళీ - ఆర్థిక లావాదేవీలు. నిజం చెప్పాలంటే, నేను వేరే ఉదాహరణ గురించి ఆలోచించలేకపోయాను.

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

8.5 నాకు ACID ఎప్పుడు అవసరం లేదు?

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

ఉదాహరణకు, ఒక వినియోగదారు వెబ్ పేజీలో వ్యాఖ్యలు లేదా స్టిక్కీ నోట్‌లను వదిలివేస్తారు. లేదా ఏదైనా సేవల ప్రదాతతో వ్యక్తిగత ఖాతాలోని వ్యక్తిగత డేటాను సవరిస్తుంది.

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

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

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

బహుశా, తదుపరి ప్రత్యక్ష ప్రసార సమయంలో కొత్త మెటీరియల్‌ని తయారు చేయడానికి విరాళాలు సేకరించే Youtube బ్లాగర్‌కి, ఎవరు, ఎప్పుడు, ఏ క్రమంలో డబ్బు విసిరారు అనేది అంత ముఖ్యమైనది కాదు.

వినియోగదారులు ఒకే వెబ్ పేజీ లేదా అప్లికేషన్ విండోలో చాలా సెకన్లు లేదా నిమిషాల పాటు ఉంటారు మరియు అందువల్ల వారు పాత డేటాను చూస్తారు.

సిద్ధాంతపరంగా, ఇవి ఏదైనా ఆన్‌లైన్ వార్తా మాధ్యమం లేదా అదే Youtube. లేదా "హబ్ర్". అసంపూర్ణ లావాదేవీలను సిస్టమ్‌లో తాత్కాలికంగా నిల్వ చేయవచ్చని మీకు పట్టింపు లేనప్పుడు, మీరు వాటిని ఎటువంటి నష్టం లేకుండా విస్మరించవచ్చు.

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