बहु-प्रदेशीय लेखन: कमिट प्रत्यक्षात कुठे पोहोचतो?
राउटिंग विनंती एका प्रदेशात पोहोचवते; केवळ व्यवहाराची सीमा लेखनाला अण्वात्मक करते। इन्व्हेरियंटला नाव द्या, मालक निवडा, नंतर त्याभोवती पुन्हा प्रयत्नाची रचना करा।
दोन प्रदेशांत दोन अनुप्रयोग सर्व्हर, 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 पॅकेट कसे प्रवास करतात आणि अपयश कसे दिसतात ते बदलते। बोगदा कितीही निरोगी दिसला तरी ती व्यवहार सीमा एका ओळीनेही वाढवत नाही। दोन्हींचा गोंधळ केल्यास अशी रचना तयार होते जिथे प्रत्येक घटक स्वतःची तपासणी उत्तीर्ण होतो आणि डेटा तरीही जुळत नाही।
दोन डेटाबेस एक प्रणाली होत नाहीत
स्वतंत्रपणे व्यवस्थापित दोन डेटाबेस क्लायंट दोन्हींपर्यंत पोहोचू शकतात या कारणाने सामायिक व्यवहार व्यवस्थापक मिळवत नाहीत। व्यवसायाला खरोखर या जोडीवर अण्वात्मक बांधिलकी हवी असल्यास, समन्वय यंत्रणा, सहभागी आणि पुनर्प्राप्ती प्रक्रिया सर्व गृहीत न धरता निवडली आणि पात्र ठरवली पाहिजे।
काम तयार झाल्यानंतर सहभागी किंवा दुवा नाहीसा होण्याच्या क्षणाचा विचार करा। समर्थित वितरित कमिट पुनर्प्राप्ती प्रक्रिया आणि मानवी निर्णय आवश्यक असलेली अनिश्चित स्थिती मागे ठेवू शकते, आणि प्रत्येक विभाजनातून प्रत्येक प्रदेश लिहिण्यायोग्य राहील असे कोणतेही वचन त्यासोबत येत नाही।
त्याऐवजी असमकालिक समन्वय स्वीकार्य असल्यास, ते स्पष्ट सांगा आणि मध्यवर्ती व्यवसाय स्थिती व समेट नियम लिहून ठेवा। भरपाईसह स्थानिक पातळीवर कमिट झालेल्या पायऱ्यांची साखळी वैध रचना आहे; ती फक्त दुसऱ्या नावाने एक अण्वात्मक व्यवहार नाही।
पहिल्या खंडापूर्वी पुन्हा प्रयत्नाची रचना करा
क्रिया कमिट झाल्यानंतर क्लायंट प्रतिसाद गमावू शकतो, त्यामुळे कॉलर कालबाह्यता अपयश मानू शकत नाही। टिकाऊ विनंती ओळख जपून ठेवा आणि बदल पुन्हा प्रयत्न करण्यापूर्वी सेवेचा निकाल किंवा निष्क्रियता यंत्रणा वापरा, अन्यथा पुन्हा प्रयत्न दुसरे लेखन बनते।
स्वयंचलित व्यवहार कॉलबॅक पुन्हा प्रयत्नयोग्य रद्दीकरणानंतर एकापेक्षा जास्त वेळा चालू शकतात, ज्यामुळे अपरिवर्तनीय बाह्य परिणामांसाठी ते वाईट घर बनतात। कार्यप्रवाहाने त्यांच्यासाठी स्पष्ट सुरक्षित प्रोटोकॉल परिभाषित केल्याशिवाय ते कॉलबॅकबाहेर ठेवा। पैसे खर्च करणाऱ्या किंवा संदेश पाठवणाऱ्या प्रत्येक गोष्टीला तीच काळजी लागू होते। दुहेरी शुल्क दुहेरी लॉग ओळीपेक्षा खूप कठीण संवाद आहे।
स्वीकृतीने चार परिस्थिती पुन्हा चालवाव्यात: एकाच ओळीसाठी स्पर्धा करणारे दोन क्लायंट, सेवा पुन्हा प्रयत्नयोग्य म्हणते असे रद्दीकरण, उत्तर कधीही न येणारे कमिट, आणि एक प्रदेश किंवा त्यांच्यातील दुव्याचे नुकसान। कमिट झालेला व्यवसाय निकाल आणि न सुटलेल्या स्थिती राउटिंग रचनेजवळ नोंदवा, जेणेकरून कोणीही नेटवर्कला हमी देणारा घटक समजू नये।