బహు-ప్రాంత రచన: కమిట్ నిజంగా ఎక్కడ చేరుతుంది?
రౌటింగ్ అభ్యర్థనను ఒక ప్రాంతానికి చేర్చుతుంది; రచనను పరమాణు చేసేది ఒక లావాదేవీ సరిహద్దు మాత్రమే. ఇన్‌వేరియంట్‌ను పేర్కొనండి, యజమానిని ఎంచుకోండి, ఆపై దాని చుట్టూ మళ్లీ ప్రయత్నాన్ని రూపొందించండి.
రెండు ప్రాంతాల్లో రెండు అప్లికేషన్ సర్వర్లు, VPN ద్వారా రాసే ఒక క్లయింట్, ఎవరూ రాయని ఒక ప్రశ్న: రచన జరిగిందని ఏ భాగం నిర్ణయిస్తుంది? రౌటింగ్ అభ్యర్థనను ప్రాసెస్‌కు చేర్చుతుంది. లావాదేవీ సరిహద్దు మార్పు ఎప్పుడు శాశ్వతంగా, కనిపించేలా మారుతుందో నిర్ణయిస్తుంది. ఇవి వేర్వేరు వ్యవస్థలు చేసే వేర్వేరు పనులు, వాటి మధ్య ఖాళీలోనే చాలా బహు-ప్రాంత రచన దోషాలు నివసిస్తాయి.
మ్యాప్ నుండి కాదు, వ్యాపార నియమం నుండి ప్రారంభించండి
భూగోళశాస్త్రం గురించి కాదు, వ్యాపార నియమం గురించి ఒక వాక్యంతో ప్రారంభించండి: ఏ పఠనాలు, రచనలు కలిసి విజయవంతం కావాలి, ఆ సమయంలో ఏ ఏకకాల మార్పులు అసాధ్యంగా ఉండాలి. స్టాక్ రిజర్వేషన్ కోసం దీని అర్థం స్టాక్ తనిఖీ, రిజర్వేషన్ రెండూ అమలులోకి వస్తాయి లేదా ఏదీ రాదు, మధ్యలో మరో ఆర్డర్ అదే యూనిట్‌ను వాడకూడదు.
| Requirement | What satisfies it | What does not |
|---|---|---|
| All-or-nothing application | A transaction inside one owning system | A VPN path between regions |
| No double spend | Isolation strong enough to exclude the conflict | Atomicity alone |
| Survive a region loss | Replication the database itself documents | Two independent databases behind one client |
సరిగ్గా ఆ మధ్య వరుసను జట్లు దాటేస్తాయి. సరిపోతున్న వేరుచేయడం లేకుండా పరమాణుత్వం రెండు లావాదేవీలు ఒక్కొక్కటి సరిగ్గా కమిట్ కావడానికి అనుమతిస్తుంది, అయినా వ్యాపారం అసాధ్యమని భావించే స్థితిని సృష్టిస్తుంది, తర్వాత ఎంత మళ్లీ ప్రయత్న తర్కమూ దాన్ని సరిచేయదు.
ఒక అధికార సరిహద్దు రెండు ప్రాంతీయ సర్వర్లను ఓడిస్తుంది
ప్రాంతీయ అప్లికేషన్ సర్వర్లు ఉన్నచోటే ఉండవచ్చు, ఆ కార్యకలాపాన్ని ఒక మద్దతు ఉన్న లావాదేవీ సరిహద్దు లోపల చేసే సేవకు అప్పగిస్తే మాత్రమే. అప్లికేషన్ పొర ఉద్దేశ్యపు రౌటర్ అవుతుంది; డేటా పొర సత్యాన్ని కలిగి ఉంటుంది.
ఆ సరిహద్దును చిన్నదిగా, అది తాకే డేటాకు దగ్గరగా ఉంచండి. మనిషి ప్రాంప్ట్‌కు సమాధానం ఇస్తున్నప్పుడు లేదా కాల్ రెండు ప్రాంతాలను దాటుతున్నప్పుడు తెరిచి ఉంచిన లావాదేవీ తన సమయాన్ని లాక్‌లు పట్టుకోవడంలో గడుపుతుంది, దాని వెనుక మరోటి గడువు మించే అవకాశాన్ని పెంచుతుంది. ఆ వైఫల్యం డేటాబేస్ సమస్యలా కనిపిస్తుంది, నిజానికి అలా వేషం వేసుకున్న రూపకల్పన సమస్య. నిర్ణయాన్ని డేటా పొరకు తరలిస్తే సాధారణంగా అది పూర్తిగా తొలగిపోతుంది.
BEGIN;
UPDATE inventory SET reserved = reserved + 1
WHERE sku = 'A-100' AND available >= 1;
INSERT INTO reservation (sku, order_id) VALUES ('A-100', 'ord-9f');
COMMIT;ఆ స్కెచ్‌ను సరిహద్దుగా చదవండి, పనితీరు సిఫారసుగా కాదు. విషయం ఏమిటంటే తనిఖీ, చొప్పింపు ఒకే కమిట్‌ను పంచుకుంటాయి, కాబట్టి ఏకకాల ఆర్డర్ స్టాక్ వాడబడినట్లు చూస్తుంది లేదా అసలు చూడదు.
ప్రతిబింబిత డేటాబేస్ ఏమి ఇస్తుంది, ఏమి ఇవ్వదు
దాని సొంత లావాదేవీ నమూనా మద్దతిస్తే ప్రతిబింబిత డేటాబేస్ విస్తృత సరిహద్దును ఇవ్వగలదు. Spanner ఒకే డేటాబేస్ లోపల పట్టికల అంతటా పరమాణు పఠన-రచన లావాదేవీలను, నిర్వచించిన వేరుచేయడం, మళ్లీ ప్రయత్న ప్రవర్తనతో నమోదు చేస్తుంది. అది మీరు చదివి, పరీక్షించి, ఉద్దేశపూర్వకంగా ఆధారపడే హామీ.
అది ఉత్పత్తి నుండి వచ్చే హామీ కూడా, మార్గం నుండి కాదు. ప్రాంతాల మధ్య VPN ప్యాకెట్లు ఎలా ప్రయాణిస్తాయో, వైఫల్యాలు ఎలా బయటపడతాయో మారుస్తుంది. సొరంగం ఎంత ఆరోగ్యంగా కనిపించినా అది లావాదేవీ సరిహద్దును ఒక వరుస కూడా పొడిగించదు. రెండింటినీ కలపడం ప్రతి భాగం తన తనిఖీని దాటే, కానీ డేటా ఇంకా సరిపోకుండా ఉండే నిర్మాణాలను సృష్టిస్తుంది.
రెండు డేటాబేస్‌లు ఒక వ్యవస్థగా మారవు
స్వతంత్రంగా నిర్వహించబడే రెండు డేటాబేస్‌లు క్లయింట్లు రెండింటినీ చేరగలరు అనే కారణంతో భాగస్వామ్య లావాదేవీ నిర్వాహకుడిని పొందవు. వ్యాపారానికి నిజంగా ఆ జంట అంతటా పరమాణు నిబద్ధత అవసరమైతే, సమన్వయ యంత్రాంగం, భాగస్వాములు, పునరుద్ధరణ ప్రక్రియ అన్నీ ఊహించకుండా ఎంచుకోవాలి, అర్హత కల్పించాలి.
పని సిద్ధమైన తర్వాత ఒక భాగస్వామి లేదా లింక్ మాయమయ్యే క్షణం గురించి ఆలోచించండి. మద్దతు ఉన్న పంపిణీ కమిట్ పునరుద్ధరణ విధానం, మానవ నిర్ణయం అవసరమయ్యే అనిశ్చిత స్థితిని వదిలివేయవచ్చు, ప్రతి విభజనలో ప్రతి ప్రాంతం రాయగలిగేలా ఉంటుందని అది ఎలాంటి వాగ్దానం చేయదు.
బదులుగా అసమకాలిక సమన్వయం ఆమోదయోగ్యమైతే, దాన్ని స్పష్టంగా చెప్పి మధ్యంతర వ్యాపార స్థితులు, సరిపోరిక నియమాలు రాయండి. పరిహారంతో స్థానికంగా కమిట్ అయిన దశల గొలుసు చెల్లుబాటు రూపకల్పన; అది వేరే పేరుతో ఒక పరమాణు లావాదేవీ మాత్రమే కాదు.
మొదటి అంతరాయానికి ముందే మళ్లీ ప్రయత్నాన్ని రూపొందించండి
కార్యకలాపం కమిట్ అయిన తర్వాత క్లయింట్ ప్రతిస్పందనను కోల్పోవచ్చు, కాబట్టి కాలర్ గడువు ముగింపును వైఫల్యంగా పరిగణించలేరు. శాశ్వత అభ్యర్థన గుర్తింపును ఉంచి, మార్పును మళ్లీ ప్రయత్నించే ముందు సేవ ఫలితం లేదా అదేతన స్థితి యంత్రాంగాన్ని వాడండి, లేకపోతే మళ్లీ ప్రయత్నం రెండవ రచన అవుతుంది.
స్వయంచాలక లావాదేవీ కాల్‌బ్యాక్‌లు మళ్లీ ప్రయత్నించదగిన రద్దు తర్వాత ఒకసారి కంటే ఎక్కువసార్లు అమలు కావచ్చు, ఇది వాటిని తిరిగి మార్చలేని బాహ్య ప్రభావాలకు చెడు నివాసంగా చేస్తుంది. వర్క్‌ఫ్లో వాటికి స్పష్టమైన సురక్షిత ప్రోటోకాల్ నిర్వచించనంత వరకు వాటిని కాల్‌బ్యాక్‌కు వెలుపల ఉంచండి. డబ్బు ఖర్చయ్యే లేదా సందేశం పంపే ప్రతిదానికీ అదే జాగ్రత్త వర్తిస్తుంది. రెట్టింపు ఛార్జీ రెట్టింపు లాగ్ లైన్ కంటే చాలా కష్టమైన సంభాషణ.
ఆమోదం నాలుగు సందర్భాలను మళ్లీ నడపాలి: ఒకే వరుస కోసం పోటీపడే ఇద్దరు క్లయింట్లు, సేవ మళ్లీ ప్రయత్నించదగినదని చెప్పే రద్దు, సమాధానం ఎప్పటికీ రాని కమిట్, ఒక ప్రాంతం లేదా వాటి మధ్య లింక్ నష్టం. కమిట్ అయిన వ్యాపార ఫలితాన్ని, పరిష్కరించని స్థితులను రౌటింగ్ రూపకల్పన పక్కన నమోదు చేయండి, ఎవరూ నెట్‌వర్క్‌ను హామీ ఇచ్చే భాగంగా పొరపాటు పడకుండా.