एक आवेदन में एसीआईडी कैसे कार्यान्वित करें: अभ्यास

8.1 लेन-देन आईडी

इसे XID या TxID के रूप में नामित किया गया है (यदि कोई अंतर है, तो मुझे बताएं)। टाइमस्टैम्प का उपयोग TxID के रूप में किया जा सकता है, जो हाथों में खेल सकता है यदि हम किसी समय में सभी क्रियाओं को पुनर्स्थापित करना चाहते हैं। समस्या उत्पन्न हो सकती है यदि टाइमस्टैम्प पर्याप्त रूप से दानेदार नहीं है - तो लेन-देन समान आईडी प्राप्त कर सकते हैं।

इसलिए, सबसे विश्वसनीय विकल्प अद्वितीय यूयूआईडी उत्पाद आईडी उत्पन्न करना है। पायथन में यह बहुत आसान है:

>>> import uuid 
>>> str(uuid.uuid4()) 
'f50ec0b7-f960-400d-91f0-c42a6d44e3d0' 
>>> str(uuid.uuid4()) 
'd15bed89-c0a5-4a72-98d9-5507ea7bc0ba' 

लेन-देन-परिभाषित डेटा का एक सेट हैश करने और इस हैश को TxID के रूप में उपयोग करने का विकल्प भी है।

8.2 पुनर्प्रयास

यदि हम जानते हैं कि एक निश्चित फ़ंक्शन या प्रोग्राम बेकार है, तो इसका मतलब है कि हम त्रुटि के मामले में इसके कॉल को दोहराने का प्रयास कर सकते हैं और करना चाहिए। और हमें बस इस तथ्य के लिए तैयार रहना होगा कि कुछ ऑपरेशन एक त्रुटि देंगे - यह देखते हुए कि आधुनिक अनुप्रयोग नेटवर्क और हार्डवेयर पर वितरित किए जाते हैं, त्रुटि को अपवाद के रूप में नहीं, बल्कि आदर्श के रूप में माना जाना चाहिए। सर्वर क्रैश, नेटवर्क एरर, रिमोट एप्लिकेशन कंजेशन के कारण त्रुटि हो सकती है। हमारे आवेदन को कैसे व्यवहार करना चाहिए? यह सही है, ऑपरेशन को दोहराने का प्रयास करें।

चूंकि कोड का एक टुकड़ा शब्दों के पूरे पृष्ठ से अधिक कह सकता है, आइए एक उदाहरण का उपयोग यह समझने के लिए करें कि भोली पुन: प्रयास तंत्र को आदर्श रूप से कैसे काम करना चाहिए। मैं इसे टेनेसिटी लाइब्रेरी का उपयोग करके प्रदर्शित करूँगा (यह इतनी अच्छी तरह से डिज़ाइन किया गया है कि भले ही आप इसका उपयोग करने की योजना नहीं बनाते हैं, उदाहरण आपको दिखाएगा कि आप पुनरावृत्ति तंत्र को कैसे डिज़ाइन कर सकते हैं):

import logging
import random
import sys
from tenacity import retry, stop_after_attempt, stop_after_delay, wait_exponential, retry_if_exception_type, before_log

logging.basicConfig(stream=sys.stderr, level=logging.DEBUG)
logger = logging.getLogger(__name__)

@retry(
	stop=(stop_after_delay(10) | stop_after_attempt(5)),
	wait=wait_exponential(multiplier=1, min=4, max=10),
	retry=retry_if_exception_type(IOError),
	before=before_log(logger, logging.DEBUG)
)
def do_something_unreliable():
	if random.randint(0, 10) > 1:
    	raise IOError("Broken sauce, everything is hosed!!!111one")
	else:
    	return "Awesome sauce!"

print(do_something_unreliable.retry.statistics)

> बस मामले में, मैं कहूंगा: \@retry(...) एक विशेष पायथन सिंटैक्स है जिसे "डेकोरेटर" कहा जाता है। यह केवल एक पुनः प्रयास (...) फ़ंक्शन है जो किसी अन्य फ़ंक्शन को लपेटता है और इसे निष्पादित करने से पहले या बाद में कुछ करता है।

जैसा कि हम देख सकते हैं, रिट्रीट को रचनात्मक रूप से डिजाइन किया जा सकता है:

• आप समय (10 सेकंड) या प्रयासों की संख्या (5) द्वारा प्रयासों को सीमित कर सकते हैं।
• चरघातांकी हो सकता है (अर्थात, 2 ** कुछ बढ़ती हुई संख्या n )। या किसी अन्य तरीके से (उदाहरण के लिए, निश्चित) अलग-अलग प्रयासों के बीच समय बढ़ाने के लिए। घातीय संस्करण को "संकुलन पतन" कहा जाता है।
• आप केवल कुछ प्रकार की त्रुटियों (IOError) के लिए पुनः प्रयास कर सकते हैं।
• लॉग में कुछ विशेष प्रविष्टियों द्वारा पुन: प्रयास को पहले या पूरा किया जा सकता है।

अब जब हमने युवा फाइटर कोर्स पूरा कर लिया है और उन बुनियादी बिल्डिंग ब्लॉक्स को जान गए हैं जिनकी हमें एप्लिकेशन साइड पर लेनदेन के साथ काम करने की आवश्यकता है, आइए दो तरीकों से परिचित हों जो हमें वितरित सिस्टम में लेनदेन को लागू करने की अनुमति देते हैं।

8.3 लेनदेन प्रेमियों के लिए उन्नत उपकरण

मैं केवल काफी सामान्य परिभाषाएँ दूंगा, क्योंकि यह विषय एक अलग बड़े लेख के योग्य है।

दो-चरण की प्रतिबद्धता (2pc) । 2pc के दो चरण हैं: एक तैयारी चरण और एक प्रतिबद्ध चरण। तैयारी के चरण के दौरान, सभी माइक्रोसर्विसेज को परमाणु रूप से किए जा सकने वाले कुछ डेटा परिवर्तनों के लिए तैयार रहने के लिए कहा जाएगा। एक बार जब वे सभी तैयार हो जाते हैं, तो प्रतिबद्ध चरण वास्तविक परिवर्तन करेगा। प्रक्रिया को समन्वित करने के लिए, एक वैश्विक समन्वयक की आवश्यकता होती है, जो आवश्यक वस्तुओं को लॉक कर देता है - अर्थात, जब तक समन्वयक उन्हें अनलॉक नहीं करता तब तक वे परिवर्तन के लिए दुर्गम हो जाते हैं। यदि कोई विशेष माइक्रोसर्विस परिवर्तन के लिए तैयार नहीं है (उदाहरण के लिए, प्रतिक्रिया नहीं करता है), तो समन्वयक लेनदेन को निरस्त कर देगा और रोलबैक प्रक्रिया शुरू कर देगा।

यह प्रोटोकॉल अच्छा क्यों है? यह परमाणुता प्रदान करता है। इसके अलावा, यह लिखते और पढ़ते समय अलगाव की गारंटी देता है। इसका मतलब यह है कि जब तक समन्वयक परिवर्तन नहीं करता तब तक एक लेनदेन में परिवर्तन दूसरों के लिए दृश्यमान नहीं होते हैं। लेकिन इन गुणों का एक नुकसान भी है: चूंकि यह प्रोटोकॉल सिंक्रोनस (ब्लॉकिंग) है, यह सिस्टम को धीमा कर देता है (इस तथ्य के बावजूद कि आरपीसी कॉल स्वयं काफी धीमी है)। और फिर से आपसी रुकावट का खतरा है।

सागा । इस पैटर्न में, सभी संबद्ध माइक्रोसर्विसेज में अतुल्यकालिक स्थानीय लेनदेन द्वारा एक वितरित लेनदेन निष्पादित किया जाता है। माइक्रोसर्विसेज एक इवेंट बस के माध्यम से एक दूसरे के साथ संवाद करते हैं। यदि कोई माइक्रोसर्विस अपने स्थानीय लेन-देन को पूरा करने में विफल रहता है, तो अन्य माइक्रोसर्विसेज परिवर्तनों को वापस लाने के लिए क्षतिपूर्ति लेनदेन करेंगे।

सागा का लाभ यह है कि कोई वस्तु अवरुद्ध नहीं होती है। लेकिन निश्चित रूप से, डाउनसाइड्स हैं।

सागा को डिबग करना कठिन है, खासकर जब इसमें कई माइक्रोसर्विसेज शामिल हों। सागा पैटर्न का एक और नुकसान यह है कि इसमें रीड आइसोलेशन का अभाव है। अर्थात्, यदि ACID में इंगित गुण हमारे लिए महत्वपूर्ण हैं, तो सागा हमारे लिए बहुत उपयुक्त नहीं है।

इन दो तकनीकों के विवरण से हम क्या देखते हैं? तथ्य यह है कि वितरित प्रणालियों में, परमाणुता और अलगाव की जिम्मेदारी आवेदन के साथ होती है। एसीआईडी ​​​​गारंटी प्रदान नहीं करने वाले डेटाबेस का उपयोग करते समय भी ऐसा ही होता है। यही है, संघर्ष समाधान, रोलबैक, कमिट और खाली स्थान जैसी चीजें डेवलपर के कंधों पर पड़ती हैं।

8.4 मुझे कैसे पता चलेगा कि मुझे कब एसीआईडी ​​​​गारंटियों की आवश्यकता है?

जब इस बात की उच्च संभावना हो कि उपयोगकर्ताओं या प्रक्रियाओं का एक निश्चित समूह एक साथ एक ही डेटा पर काम करेगा ।

तुच्छता के लिए क्षमा करें, लेकिन एक विशिष्ट उदाहरण वित्तीय लेनदेन है।

जब जिस क्रम में लेन-देन निष्पादित किया जाता है वह मायने रखता है।

कल्पना करें कि आपकी कंपनी फनीयेलोचैट मैसेंजर से फनीरेडचैट मैसेंजर पर स्विच करने वाली है, क्योंकि फनीरेडचैट आपको जिफ भेजने की अनुमति देता है, लेकिन फनीयेलोचैट ऐसा नहीं कर सकता। लेकिन आप केवल संदेशवाहक नहीं बदल रहे हैं - आप अपनी कंपनी के पत्राचार को एक संदेशवाहक से दूसरे संदेशवाहक में स्थानांतरित कर रहे हैं। आप ऐसा इसलिए करते हैं क्योंकि आपके प्रोग्रामर कार्यक्रमों और प्रक्रियाओं को कहीं केंद्रीय रूप से दस्तावेज करने के लिए बहुत आलसी थे, और इसके बजाय उन्होंने मैसेंजर में विभिन्न चैनलों में सब कुछ प्रकाशित किया। हां, और आपके सेल्सपर्सन ने बातचीत और समझौतों का विवरण एक ही स्थान पर प्रकाशित किया। संक्षेप में, आपकी कंपनी का पूरा जीवन वहाँ है, और चूंकि किसी के पास दस्तावेज़ीकरण के लिए पूरी चीज़ को एक सेवा में स्थानांतरित करने का समय नहीं है, और तत्काल दूतों की खोज अच्छी तरह से काम करती है, आपने मलबे को साफ करने के बजाय बस सभी को कॉपी करने का फैसला किया एक नए स्थान पर संदेश। संदेशों का क्रम महत्वपूर्ण है

वैसे आमतौर पर संदेशवाहक में पत्राचार के लिए आदेश महत्वपूर्ण होता है, लेकिन जब दो लोग एक ही समय में एक ही चैट में कुछ लिखते हैं, तो सामान्य तौर पर यह इतना महत्वपूर्ण नहीं होता है कि किसका संदेश पहले दिखाई देगा। इसलिए, इस विशेष परिदृश्य के लिए, ACID की आवश्यकता नहीं होगी।

एक अन्य संभावित उदाहरण जैव सूचना विज्ञान है। मुझे यह बिल्कुल समझ में नहीं आता है, लेकिन मैं मानता हूं कि मानव जीनोम की व्याख्या करते समय यह आदेश महत्वपूर्ण है। हालाँकि, मैंने सुना है कि जैव सूचना विज्ञान विशेषज्ञ आमतौर पर हर चीज के लिए अपने कुछ उपकरणों का उपयोग करते हैं - शायद उनके पास अपना डेटाबेस है।

जब आप किसी उपयोगकर्ता को नहीं दे सकते या पुराने डेटा को संसाधित नहीं कर सकते।

और फिर - वित्तीय लेनदेन। सच कहूं तो मुझे कोई दूसरा उदाहरण नहीं सूझ रहा था।

जब लंबित लेनदेन महत्वपूर्ण लागतों से जुड़े होते हैं। उन समस्याओं की कल्पना करें जो तब उत्पन्न हो सकती हैं जब एक डॉक्टर और एक नर्स दोनों रोगी रिकॉर्ड को अपडेट करते हैं और एक ही समय में एक दूसरे के परिवर्तनों को मिटा देते हैं, क्योंकि डेटाबेस लेन-देन को अलग नहीं कर सकता है। स्वास्थ्य सेवा प्रणाली वित्त के अलावा एक अन्य क्षेत्र है, जहां एसीआईडी ​​​​गारंटी महत्वपूर्ण होती है।

8.5 मुझे कब एसीआईडी ​​​​की आवश्यकता नहीं है?

जब उपयोगकर्ता अपने कुछ निजी डेटा को ही अपडेट करते हैं।

उदाहरण के लिए, एक उपयोगकर्ता किसी वेब पेज पर टिप्पणियां या स्टिकी नोट्स छोड़ता है। या किसी भी सेवा के प्रदाता के साथ व्यक्तिगत खाते में व्यक्तिगत डेटा संपादित करता है।

जब उपयोगकर्ता डेटा को बिल्कुल भी अपडेट नहीं करते हैं, लेकिन केवल नए के साथ पूरक (संलग्न) करते हैं।

उदाहरण के लिए, एक रनिंग एप्लिकेशन जो आपके रन पर डेटा बचाता है: आप कितना दौड़े, किस समय, मार्ग, आदि। प्रत्येक नया रन नया डेटा है, और पुराने बिल्कुल संपादित नहीं होते हैं। शायद, डेटा के आधार पर, आपको एनालिटिक्स मिलते हैं - और इस परिदृश्य के लिए सिर्फ NoSQL डेटाबेस अच्छे हैं।

जब व्यापार तर्क एक निश्चित क्रम की आवश्यकता को निर्धारित नहीं करता है जिसमें लेनदेन किया जाता है।

संभवतः, एक Youtube ब्लॉगर के लिए जो अगले लाइव प्रसारण के दौरान नई सामग्री के उत्पादन के लिए दान एकत्र करता है, यह इतना महत्वपूर्ण नहीं है कि किसने, कब और किस क्रम में उसे पैसे फेंके।

जब उपयोगकर्ता एक ही वेब पेज या एप्लिकेशन विंडो पर कई सेकंड या मिनट तक रहेंगे, और इसलिए वे किसी तरह पुराना डेटा देखेंगे।

सैद्धांतिक रूप से, ये कोई भी ऑनलाइन समाचार मीडिया या वही Youtube हैं। या "हैबर"। जब आपके लिए यह मायने नहीं रखता है कि अधूरे लेन-देन को सिस्टम में अस्थायी रूप से संग्रहीत किया जा सकता है, तो आप उन्हें बिना किसी नुकसान के अनदेखा कर सकते हैं।

यदि आप कई स्रोतों से डेटा एकत्र कर रहे हैं, और डेटा जो उच्च आवृत्ति पर अद्यतन किया जाता है - उदाहरण के लिए, किसी शहर में पार्किंग स्थानों के अधिभोग पर डेटा जो कम से कम हर 5 मिनट में बदलता है, तो सिद्धांत रूप में यह कोई बड़ी समस्या नहीं होगी आपके लिए यदि किसी बिंदु पर किसी एक पार्किंग स्थल के लिए लेन-देन पूरा नहीं होगा। हालाँकि, निश्चित रूप से, यह इस बात पर निर्भर करता है कि आप इस डेटा के साथ वास्तव में क्या करना चाहते हैं।