બહુ-પ્રદેશ લખાણ: કમિટ ખરેખર ક્યાં પહોંચે છે?
રાઉટિંગ વિનંતીને એક પ્રદેશમાં પહોંચાડે છે; ફક્ત ટ્રાન્ઝેક્શન સીમા જ લખાણને પરમાણુ બનાવે છે. ઇન્વેરિયન્ટનું નામ આપો, માલિક પસંદ કરો, પછી તેની આસપાસ ફરી પ્રયાસ ડિઝાઇન કરો.
બે પ્રદેશોમાં બે એપ્લિકેશન સર્વર, 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 બદલે છે કે પેકેટ કેવી રીતે મુસાફરી કરે છે અને નિષ્ફળતાઓ કેવી રીતે દેખાય છે. ટનલ કેટલી સ્વસ્થ દેખાય તે પ્રમાણે તે એક પંક્તિ પણ ટ્રાન્ઝેક્શન સીમા લંબાવતું નથી. બંનેને ભેગાં કરવાથી એવી આર્કિટેક્ચર બને છે જ્યાં દરેક ઘટક પોતાની ચકાસણી પાસ કરે છે અને ડેટા તેમ છતાં મેળ ખાતો નથી.
બે ડેટાબેઝ એક સિસ્ટમ બનતા નથી
સ્વતંત્ર રીતે સંચાલિત બે ડેટાબેઝ શેર કરેલ ટ્રાન્ઝેક્શન મેનેજર મેળવતા નથી કારણ કે ક્લાયન્ટ બંને સુધી પહોંચી શકે છે. જો વ્યવસાયને ખરેખર આ જોડીમાં પરમાણુ પ્રતિબદ્ધતાની જરૂર હોય, તો સંકલન પદ્ધતિ, સહભાગીઓ અને પુનઃપ્રાપ્તિ પ્રક્રિયા બધું ધારી લેવાને બદલે પસંદ કરવું અને લાયક ઠેરવવું પડે.
એ ક્ષણ વિશે વિચારો જ્યારે કામ તૈયાર થયા પછી કોઈ સહભાગી કે કડી અદૃશ્ય થાય. સમર્થિત વિતરિત કમિટ શંકાસ્પદ સ્થિતિ છોડી શકે છે જેને પુનઃપ્રાપ્તિ પ્રક્રિયા અને માનવીય નિર્ણયની જરૂર પડે, અને તે એવું કોઈ વચન આપતું નથી કે દરેક વિભાજન દરમિયાન દરેક પ્રદેશ લખી શકાય તેવો રહેશે.
જો તેના બદલે અસમકાલિક સંકલન સ્વીકાર્ય હોય, તો તે સ્પષ્ટ રીતે કહો અને મધ્યવર્તી વ્યવસાય સ્થિતિઓ તથા સમાધાન નિયમો લખો. વળતર સાથે સ્થાનિક રીતે કમિટ થયેલા પગલાંની સાંકળ કાયદેસર ડિઝાઇન છે; તે ફક્ત બીજા નામ હેઠળનું એક પરમાણુ ટ્રાન્ઝેક્શન નથી.
પહેલા વિક્ષેપ પહેલાં ફરી પ્રયાસ ડિઝાઇન કરો
ઑપરેશન કમિટ થયા પછી ક્લાયન્ટ પ્રતિસાદ ગુમાવી શકે છે, તેથી કૉલર સમયસીમાને નિષ્ફળતા ગણી શકે નહીં. ટકાઉ વિનંતી ઓળખ સાચવો અને બદલાવ ફરી અજમાવતા પહેલાં સેવાનું પરિણામ કે નિષ્ક્રિયતા પદ્ધતિ વાપરો, નહીંતર ફરી પ્રયાસ બીજું લખાણ બની જાય છે.
સ્વચાલિત ટ્રાન્ઝેક્શન કૉલબેક ફરી પ્રયાસપાત્ર રદ પછી એક કરતાં વધુ વાર ચાલી શકે છે, જે તેમને ઉલટાવી ન શકાય તેવી બાહ્ય અસરો માટે ખરાબ ઘર બનાવે છે. જ્યાં સુધી કાર્યપ્રવાહ તેમના માટે સ્પષ્ટ સુરક્ષિત પ્રોટોકોલ નક્કી ન કરે ત્યાં સુધી તેમને કૉલબેકની બહાર રાખો. એ જ સાવધાની પૈસા ખર્ચે છે અથવા સંદેશ મોકલે છે તેવી દરેક વસ્તુને લાગુ પડે છે. બમણું ચાર્જ બમણી લોગ લાઇન કરતાં ઘણી વધુ મુશ્કેલ વાતચીત છે.
સ્વીકૃતિએ ચાર પરિસ્થિતિઓ ફરી ચલાવવી જોઈએ: એ જ પંક્તિ માટે હરીફાઈ કરતા બે ક્લાયન્ટ, સેવા જે રદને ફરી પ્રયાસપાત્ર કહે છે, એવી કમિટ જેનો જવાબ કદી આવતો નથી, અને એક પ્રદેશ કે તેમની વચ્ચેની કડીનું નુકસાન. કમિટ થયેલું વ્યવસાય પરિણામ અને ઉકેલાયેલા ન હોય તેવી સ્થિતિઓ રાઉટિંગ ડિઝાઇનની બાજુમાં નોંધો, જેથી કોઈ નેટવર્કને બાંયધરી આપતા ઘટક સાથે ભૂલ ન કરે.