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