Table of Contents
सर्वर रहित डेटा स्टोर में डेटा संगति की चुनौती को समझना
सर्वर रहित डेटा स्टोर जैसे अमेज़न डायनेमोडीबी, एज़्योर कॉस्मोस डीबी, और गूगल क्लाउड फायरस्टोर ऑटो स्केलिंग, पे-प्रति-उपयोग मूल्य निर्धारण और परिचालन ओवरहेड को कम करते हैं। हालांकि, उनका वितरित प्रकृति डेटा स्थिरता में मौलिक व्यापार-बंद को पेश करती है। जब एक एप्लिकेशन तुरंत डेटा को लिखने के बाद डेटा पढ़ता है, तो उपयोगकर्ता नवीनतम मूल्य देखने की उम्मीद करता है। वैश्विक रूप से वितरित प्रणाली में, यह सुनिश्चित करने के लिए कि गारंटी गैर-ट्रियल हो जाती है। CAP theorem] हमें याद दिलाता है कि एक वितरित डेटा स्टोर केवल दो गारंटी प्रदान कर सकता है: संगतता, मूल्यांकन, और विभाजन क्षमता पहले।
डेटा स्थिरता एक आकार-फिट-सभी संपत्ति नहीं है। विभिन्न कार्यभारों को विभिन्न गारंटी की आवश्यकता होती है। उदाहरण के लिए, एक ई-कॉमर्स सूची प्रणाली को कभी भी वस्तुओं को ओवरसेल नहीं करना चाहिए, जो स्टॉक अद्यतनों के लिए मजबूत स्थिरता की मांग करती है। दूसरी तरफ एक सोशल मीडिया फीड, कुछ सेकंड के अंतराल को सहन कर सकता है जबकि एक नया पोस्ट प्रोपेगेट करता है। सही स्थिरता मॉडल चुनना और पूरक पैटर्न को लागू करना यह सुनिश्चित करता है कि आपका सर्वर रहित एप्लिकेशन भविष्य में व्यवहार करता है जबकि अभी भी मंच की लोच से लाभान्वित हो रहा है।
सर्वर रहित स्टोर में संगति मॉडल
सशक्तिकरण
मजबूत स्थिरता की गारंटी है कि हर पढ़ा हाल के लेखन को सबसे अधिक वापस ले जाता है। सर्वर रहित प्रणालियों में, यह अक्सर प्राथमिक प्रतिकृति से पढ़ने या कोरम आधारित प्रोटोकॉल का उपयोग करके हासिल किया जाता है। डायनमोडीबी समर्थन ]] जैसे सेवाएं मजबूत रूप से सुसंगत पढ़ता है (एक अतिरिक्त लागत और विलंबता पर) और Azure Cosmos DB बहु-मास्टर प्रतिकृति का उपयोग करके वैश्विक रूप से वितरित खातों के लिए मजबूत स्थिरता प्रदान करता है। वित्तीय लेनदेन, उपयोगकर्ता प्रमाणीकरण, या आरक्षण प्रणाली के लिए पूर्ण सटीकता की आवश्यकता होती है जब मजबूत स्थिरता का उपयोग करें।
घटना
वर्तमान में, यह सबसे अधिक सर्वर रहित डेटा स्टोरों के लिए डिफ़ॉल्ट है। इसका मतलब यह है कि यदि कोई नया लिखने डेटा आइटम पर नहीं बनाया जाता है, तो अंततः (आमतौर पर मिलीसेकेंड या सेकंड के भीतर) सभी प्रतिकृतियां समान मान पर निर्भर होंगी। यह मॉडल सर्वोत्तम उपलब्धता और न्यूनतम विलंबता प्रदान करता है। यह पठन-भार कार्यभार, उत्पाद सूची और लॉगिंग सिस्टम के लिए आदर्श है जहां छोटी खिड़कियों के लिए कहानी पढ़ने योग्य हैं।
कांस्टेंसी
कारण स्थिरता कारण से संबंधित कार्यों के आदेश को बरकरार रखती है। यदि ऑपरेशन A (update Profile picture) ऑपरेशन B (post a comment संदर्भित करता है कि चित्र), तो कोई पर्यवेक्षक B से पहले A को देखेगा। यह मॉडल मजबूत और ईवेंटल स्थिरता के बीच बैठता है और सेवाओं जैसे गूगल क्लाउड डेटास्टोर द्वारा समर्थित है। यह सहयोगी संपादन, सामाजिक फ़ीड और चैट अनुप्रयोगों के लिए उपयोगी है जहां घटना के आदेश के मामले।
स्थिरता बनाए रखने के लिए सर्वश्रेष्ठ अभ्यास
1. प्रत्येक ऑपरेशन के लिए उपयुक्त संगत मॉडल का चयन करें
अपने पूरे आवेदन के लिए एक एकल स्थिरता स्तर चुनने के बजाय, प्रत्येक महत्वपूर्ण पढ़ने या लिखने के संचालन को अपनी स्वयं की स्थिरता की आवश्यकता के साथ डिजाइन करें। डायनमोडीबी में, आप व्यक्तिगत के लिए या ]] को निर्दिष्ट कर सकते हैं, जबकि अन्य पढ़ने के बाद अंततः सुसंगत होते हैं। यह हाइब्रिड दृष्टिकोण प्रदर्शन और शुद्धता को संतुलित करता है। स्वीकार्य सीमाओं के भीतर विलंबता रहने को सुनिश्चित करने के लिए अपने निर्णयों को दस्तावेज करें और उन्हें लोड के तहत परीक्षण करें।
2. Sagas या दो-चरण कमिट के साथ वितरित लेनदेन का उपयोग करें
जब एक व्यवसाय प्रक्रिया एकाधिक डेटा स्टोर या सेवाओं को फैलती है, तो आपको परमाणुता बनाए रखने के लिए एक तंत्र की आवश्यकता होती है। वितरित लेनदेन - जैसे कि दो चरण के लिए प्रतिबद्ध (2PC) प्रोटोकॉल - यह सुनिश्चित करें कि प्रत्येक भाग लेने वाला पक्ष या तो एक साथ मिलकर काम करता है या गर्भपात करता है। हालांकि, 2PC धीमी हो सकता है और उपलब्धता को कम कर सकता है। एक विकल्प ]Saga पैटर्न [FLT: 3]] है, जहां प्रत्येक ऑपरेशन एक ऐसी घटना को उत्सर्जित करता है जो कुछ असफल होने पर कार्रवाई की क्षतिपूर्ति करता है। कई सर्वर रहित प्लेटफॉर्म बिल्ट-इन लेनदेन समर्थन प्रदान करते हैं: [[FLT:]]
3. संघर्ष संकल्प रणनीतियाँ लागू करना
समवर्ती एक बहु क्षेत्र तैनाती में एक ही डेटा आइटम को लिखते हैं, संघर्ष पैदा कर सकते हैं। सर्वर रहित स्टोर आम तौर पर ]last-writer-wins (LWW)] का उपयोग करते हैं, जो हाल के समय में सबसे अधिक समय तक रहता है। जबकि सरल, LWW सिंक से बाहर होने पर डेटा खो सकता है। अमीर semantics के लिए, ] का उपयोग करें।
4. लाभ Idempotent संचालन और Retries
नेटवर्क विफलताओं या क्षणिक त्रुटियों के कारण क्लाइंट रिट्राइज़ हो सकता है, जिसके परिणामस्वरूप डुप्लिकेट प्रोसेसिंग हो सकती है। डिजाइनिंग ऑपरेशन idempotent] उस जोखिम को समाप्त करता है। उदाहरण के लिए, प्रत्येक लिखित अनुरोध के लिए एक अद्वितीय विचारधारा कुंजी निर्दिष्ट करें; सर्वर तब अनुरोधों को डुप्लिकेट कर सकता है जो एक ही कुंजी साझा करता है। कई सर्वर रहित SDKs मूल रूप से idempotent लिखते हैं। इस को एक्सोनेंशियल बैकऑफ और रिट्री लॉज में वापस करने के लिए जोड़ते हैं ताकि कंटेंटेशन को कम किया जा सके और बैकएंड को भारी किए बिना स्थिरता बनाए रखा जा सके।
5. चेंज स्ट्रीम्स और ऑडिट के साथ डेटा अखंडता की निगरानी करें
सर्वर रहित वातावरण में आप ]चेंज डेटा कैप्चर (CDC) का उपयोग कर सकते हैं जैसे डायनमोडीबी स्ट्रीम, कॉस्मोस डीबी चेंज फीड, या फायरस्टोर के वास्तविक समय श्रोता सभी संशोधनों की निगरानी के लिए। एक लैम्ब्डा या क्लाउड फंक्शन को यह मान्य करने के लिए कि डेटा इनवरेंट प्रत्येक परिवर्तन के बाद पकड़ते हैं। उदाहरण के लिए, एक बैंकिंग एप्लिकेशन खाते के लेनदेन की सदस्यता ले सकता है और सत्यापित कर सकता है कि संतुलन हमेशा क्रेडिट माइनस डेबिट की राशि के बराबर होता है। नियमित लेखा परीक्षा क्वेरीज़ - एक अनुसूची पर चलाएं - बहाव और ट्रिगर सही वर्कफ़्लो का पता लगा सकते हैं।
6. अपने उपयोग के मामले के लिए डेटा प्रतिकृति का अनुकूलन करें
वैश्विक प्रतिकृति दुनिया भर के उपयोगकर्ताओं के लिए विलंबता में सुधार करती है लेकिन असंगति के लिए खिड़की को बढ़ाता है। उचित स्थिरता स्तर के साथ प्रतिकृति को कॉन्फ़िगर करें और ]सक्रिय-] बनाम ]]सक्रिय-passive] topology. सक्रिय-सक्रिय (multi-master) कम लिखने की विलंबता प्रदान करता है लेकिन मजबूत संघर्ष संकल्प की आवश्यकता होती है। सक्रिय-निष्क्रिय (एकल प्राथमिक पढ़ने वाली प्रतिकृति के साथ) लिखते समय मजबूत स्थिरता प्रदान करता है जबकि अभी भी निकटतम प्रतिकृति से पढ़ता है। Cosmos DB जैसी सेवाएं पांच अच्छी तरह से परिभाषित स्तर से चुनती हैं।
वास्तुकला पैटर्न जो कंसिस्टेंसी को संरक्षित करते हैं
कमांड क्वेरी जिम्मेदारी अलगाव (CQRS)
CQRS पढ़ने वाले मॉडल से मॉडल लिखने को अलग करता है, जिससे प्रत्येक को स्वतंत्र रूप से अनुकूलित करने की अनुमति मिलती है। राइट्स एक दृढ़ता से संगत स्टोर पर जाते हैं; अंततः लगातार अनुमानों से पढ़ते हैं। यह पैटर्न विशेष रूप से शक्तिशाली है जब एक event sourcing दृष्टिकोण, जहां सभी राज्य परिवर्तन अचल घटनाओं के रूप में संग्रहीत किए जाते हैं। पढ़ने वाले मॉडल को घटना लॉग से पुनर्निर्माण किया जा सकता है यदि स्थिरता के मुद्दे कभी उत्पन्न होते हैं। मार्टिन फाउलर का ]CQRS पर लेख एक उत्कृष्ट अवलोकन प्रदान करता है।
घटना सोर्सिंग और घटनात्मक स्थिरता
घटना सोर्सिंग वर्तमान स्थिति के बजाय घटनाओं का एक अनुक्रम स्टोर करता है। क्योंकि घटनाएं केवल और अपरिवर्तनीय हैं, वे स्वाभाविक रूप से सुसंगत हैं। डायनमोडीबी या कॉस्मो डीबी जैसी सेवाएं घटना स्टोर के रूप में कार्य कर सकती हैं। उपभोक्ता प्रक्रिया की घटनाओं को अतुल्यकालिक रूप से, अंततः पढ़ने के मॉडल का निर्माण करते हैं। एक संघर्ष के दुर्लभ मामले में, आप एक ज्ञात चेकपॉइंट से घटना स्ट्रीम को फिर से चला सकते हैं। यह पैटर्न सुनिश्चित करता है कि Durability और श्रवण क्षमता जबकि यह स्थिरता सीमाओं के बारे में कारण के लिए सीधा बना रहा है।
विश्वसनीय संदेश के लिए आउटबॉक्स पैटर्न
जब एक सर्वर रहित फ़ंक्शन डेटाबेस को लिखते हैं और फिर एक कतार को संदेश भेजता है, तो दो ऑपरेशन परमाणु नहीं हो सकते हैं। आउटबॉक्स पैटर्न इस को उसी लेनदेन के भीतर उसी डेटाबेस में संदेश को संग्रहीत करके हल करता है। एक अलग प्रक्रिया (जैसे स्ट्रीम प्रोसेसर) आउटबॉक्स को पढ़ती है और संदेश प्रकाशित करती है। यह गारंटी देता है कि डेटाबेस लिखने और संदेश भेजने दोनों प्रतिबद्ध हैं या दोनों वापस लुढ़का, सेवाओं के पार स्थिरता को संरक्षित करते हैं। AWS प्रदाताओं जैसे AWS Well-Architected ने आउटबॉक्स पैटर्न [F: 3LT] विस्तार में वर्णन किया है।
विशेष मामलों को संभालने: भू-वितरण और ऑफलाइन राइट्स
मोबाइल और आईओटी अनुप्रयोग अक्सर ऑफ़लाइन काम करते हैं और बाद में सिंक करते हैं। सर्वर रहित विक्रेता SDKs सिंक्रनाइज़ेशन के साथ ऑफ़लाइन दृढ़ता प्रदान करते हैं जो कस्टम संघर्षों को हल करने वालों के माध्यम से संघर्षों को संभालती है। उदाहरण के लिए, डायनामोडीबी के साथ AWS AppSync टाइमस्टैम्प या क्लाइंट-डिफ़ाइन लॉजिक के आधार पर संस्करणों को मर्ज कर सकता है। ऐसे पुस्तकालयों का उपयोग करते समय, हमेशा वास्तविक दुनिया के नेटवर्क स्थितियों के तहत संघर्ष के संकल्प तर्क का परीक्षण करते हैं और संघर्षों की संख्या की निगरानी करते हैं।
बहु क्षेत्र की स्थिरता के लिए, का उपयोग करें, समेकन समूहों जहां संभव हो - Cosmos DB द्वारा समर्थित एक अवधारणा जो संबंधित वस्तुओं को समूह बनाती है ताकि वे हमेशा एक साथ दोहराई जा सकें। यह परिदृश्यों को रोकता है जहां एक उपयोगकर्ता की प्रोफ़ाइल तस्वीर को क्षेत्र ए में अपडेट किया गया है लेकिन उनका जैव अद्यतन (एक ही समूह में) अभी तक क्षेत्र बी में नहीं आया है।
परीक्षण और सत्यापन रणनीतियाँ
संगति बग अक्सर केवल वितरित भार के तहत सतह होती है। एकीकरण परीक्षण लिखें जो वास्तविक सर्वर रहित एमुलेटर या क्लाउड उदाहरण के खिलाफ चल रहे हैं और समवर्ती लिखते हैं और पढ़ते हैं। जैसे उपकरण Jepsen] सत्यापित कर सकते हैं कि आपका डेटा स्टोर नेटवर्क विभाजन के तहत सही ढंग से व्यवहार करता है। उत्पादन के लिए, कैनरी तैनाती को लागू करें और धीरे-धीरे स्थिरता मीट्रिक की निगरानी करते समय नए कोड पथ पर यातायात को स्थानांतरित करें।
सारांश
सर्वर रहित डेटा स्टोर में डेटा स्थिरता को जानबूझकर वास्तुशिल्प विकल्प की आवश्यकता होती है। उपलब्ध स्थिरता मॉडल को समझने के लिए, वितरित लेनदेन या सागा पैटर्न को नियोजित करना, विचारधारा संचालन को डिजाइन करना और संघर्ष संकल्प तंत्र का लाभ उठाना, आप उन अनुप्रयोगों का निर्माण कर सकते हैं जो स्केलेबल और विश्वसनीय दोनों हैं। अपने सिस्टम की स्थिरता को मॉनिटर करें परिवर्तन धाराओं और ऑडिट के माध्यम से गारंटी देता है, और सीक्यूआरएस, इवेंट सोर्सिंग और आउटबॉक्स पैटर्न को सेवा सीमाओं में अखंडता बनाए रखने के लिए अपनाता है। इन सर्वोत्तम प्रथाओं के साथ, आपका सर्वर रहित बैकएंड अपने उपयोगकर्ताओं को एक सुसंगत, सही अनुभव प्रदान करेगा - यहां तक कि वैश्विक यातायात को संभालने के लिए यह स्केल करता है।