🔪 🆓 🍒 उन त्रुटियों के बारे में जो कहीं से भी नहीं निकलती हैं और जिसमें कोई भी दोषी नहीं है: जिम्मेदारी के धब्बा की घटना 👨‍🍳 🐒 🍔

लेख गैर जिम्मेदार कर्मचारियों के बारे में बात नहीं करेगा , क्योंकि कोई भी लेख के शीर्षक से सुझाव दे सकता है। यदि आप वितरित सिस्टम बनाते हैं तो हम एक वास्तविक तकनीकी खतरे पर चर्चा करेंगे।

एक एंटरप्राइज सिस्टम में, एक घटक था। इस घटक ने एक निश्चित उत्पाद के बारे में उपयोगकर्ताओं से डेटा एकत्र किया और इसे डेटा बैंक में दर्ज किया। और इसमें तीन मानक भाग शामिल थे: उपयोगकर्ता इंटरफ़ेस, सर्वर पर व्यापार तर्क और डेटाबेस में टेबल।

घटक ने अच्छी तरह से काम किया, और कई सालों तक किसी ने इसके कोड को नहीं छुआ।

लेकिन एक बार, बिना किसी कारण के, घटक को अजीब चीजें होने लगीं।

जब कुछ उपयोगकर्ताओं के साथ काम करते हैं, तो सत्र के बीच में एक घटक अचानक त्रुटियों को फेंकना शुरू कर देता है। यह बार-बार होता है, लेकिन हमेशा की तरह, सबसे अपर्याप्त समय पर। और जो सबसे अधिक समझ से बाहर है, पहली त्रुटियां उत्पादन में सिस्टम के एक स्थिर संस्करण में दिखाई दीं। उस संस्करण में जिसमें कई महीनों तक कोई भी घटक बिल्कुल नहीं बदले गए थे।

हमने स्थिति का विश्लेषण करना शुरू किया। हमने भारी भार के तहत घटक की जांच की। यह अच्छी तरह से काम करता है। काफी व्यापक एकीकरण परीक्षण दोहराया। एकीकरण परीक्षणों में, हमारे घटक ने ठीक काम किया।

एक शब्द में, त्रुटि स्पष्ट नहीं हुई कि कब और कहां अस्पष्ट।

वे गहरी खुदाई करने लगे। लॉग फ़ाइलों की एक विस्तृत विश्लेषण और तुलना से पता चला कि उपयोगकर्ता को दिखाए गए त्रुटि संदेशों का कारण डेटाबेस में पहले से उल्लेखित तालिका में प्राथमिक कुंजी में उल्लंघन है।

घटक ने हाइबरनेट का उपयोग करके तालिका में डेटा लिखा, और कभी-कभी हाइबरनेट, जब अगली पंक्ति लिखने की कोशिश कर रहा था, तो एक बाधा उल्लंघन की सूचना दी।

मैं आगे के तकनीकी विवरण के साथ पाठकों को बोर नहीं करूंगा और तुरंत आपको त्रुटि के सार के बारे में बताऊंगा। यह पता चला कि न केवल हमारा घटक उपरोक्त तालिका में लिखता है, बल्कि कभी-कभी (अत्यंत दुर्लभ) कुछ अन्य घटक। और वह एक साधारण SQL INSERT स्टेटमेंट के साथ बहुत सरलता से करती है। एक हाइबरनेट डिफ़ॉल्ट रूप से काम करता है जब निम्नानुसार लिखते हैं। लेखन प्रक्रिया को अनुकूलित करने के लिए, यह सूचकांक में एक बार अगली प्राथमिक कुंजी के सूचकांक पर सवाल उठाता है, और फिर कई बार बस मुख्य मूल्य को बढ़ाता है (डिफ़ॉल्ट रूप से 10 गुना)। और अगर ऐसा हुआ कि अनुरोध के बाद, दूसरा घटक प्रक्रिया में फंस गया और निम्न प्राथमिक कुंजी मूल्य का उपयोग करके तालिका में डेटा लिखा, तो हाइबरनेट से लिखने के बाद के प्रयास ने बाधा का उल्लंघन किया।
यदि आप तकनीकी विवरण में रुचि रखते हैं, तो उन्हें नीचे देखें।

तकनीकी विवरण

।
वर्ग कोड इस तरह शुरू हुआ:

@Entity @Table(name="PRODUCT_XXX") public class ProductXXX {                               @Id                @Basic(optional=false)                @Column(                                name="PROD_ID",                                columnDefinition="integer not null",                                insertable=true,                                updatable=false)                @SequenceGenerator(                                name="GEN_PROD_ID",                                sequenceName="SEQ_PROD_ID",                                allocationSize=10)                @GeneratedValue(                                strategy=GenerationType.SEQUENCE,                                generator="GEN_PROD_ID")                private long prodId;

Stackoverflow पर एक समान मुद्दे की एक चर्चा:
https://stackoverflow.com/questions/12745751/hibernate-sequencegenerator-and-allocationsize

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

खैर, एकीकरण परीक्षण सुचारू रूप से चले गए, क्योंकि एकीकरण परीक्षण के अंदर दोनों घटकों के परीक्षण के लिए समय अंतराल या तो प्रतिच्छेद नहीं किया था।

एक तरह से, हम यह कह सकते हैं कि कोई भी त्रुटि के लिए दोषी नहीं था।

या ऐसा नहीं है?

अवलोकन और विचार

त्रुटि के वास्तविक कारण की खोज करने के बाद, इसे सही किया गया था।

लेकिन इस सुखद अंत के साथ, मैं इस लेख को समाप्त करना चाहता हूं, लेकिन इस त्रुटि को उस विशाल श्रेणी की त्रुटियों के प्रतिनिधि के रूप में प्रतिबिंबित करता हूं, जिसने अखंड से वितरित प्रणालियों में संक्रमण के बाद लोकप्रियता हासिल की है।

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

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

वितरित प्रणालियों, विशेष रूप से माइक्रोसिस्टर्स की अवधारणा ने प्रभावी रूप से अखंड प्रणालियों में निहित कई समस्याओं को हल करने में मदद की है। हालांकि, विरोधाभासी रूप से, व्यक्तिगत सेवाओं के लिए जिम्मेदारियों का अलग होना विपरीत प्रभाव को उकसाता है। घटक अब "लाइव" जितना संभव हो उतना स्वतंत्र हैं। और अनिवार्य रूप से एक प्रलोभन है, एक घटक को बड़ा बदलाव करते हुए, "ठीक यहां पेंच" करने के लिए थोड़ा कार्यक्षमता है जो दूसरे घटक में बेहतर तरीके से लागू किया जाएगा। यह जल्दी से अंतिम प्रभाव को प्राप्त करता है, अनुमोदन और परीक्षण की मात्रा को कम करता है। इसलिए, परिवर्तन से परिवर्तन तक, घटकों को उनके लिए असामान्य सुविधाओं के साथ उखाड़ फेंका जाता है, एक ही आंतरिक एल्गोरिदम और कार्यों को दोहराया जाता है, समस्या को हल करने के बहुपक्षीय (और कभी-कभी उनका गैर-निर्धारणवाद) उत्पन्न होता है। दूसरे शब्दों में, एक वितरित प्रणाली समय के साथ खराब हो जाती है, लेकिन एक अखंड से अलग।

कई सेवाओं से युक्त बड़े सिस्टम में घटकों के लिए "स्मियरिंग" जिम्मेदारी आधुनिक वितरित प्रणालियों की विशिष्ट और दर्दनाक समस्याओं में से एक है। साझा अनुकूलन सबसिस्टम जैसे कैशिंग, निम्न संचालन की भविष्यवाणी (भविष्यवाणी), साथ ही सेवाओं के ऑर्केस्ट्रेशन, आदि से स्थिति और अधिक जटिल और उलझन में है।

डेटाबेस तक पहुंच को केंद्रीकृत करना, कम से कम एकल पुस्तकालय के स्तर पर, आवश्यकता काफी स्पष्ट है। हालाँकि, कई आधुनिक वितरित सिस्टम ऐतिहासिक रूप से डेटाबेस के आसपास विकसित हुए हैं और एक्सेस सेवाओं के माध्यम से सीधे (SQL के माध्यम से) उन में संग्रहीत डेटा का उपयोग करते हैं।

हाइबरनेट की तरह जिम्मेदारी और ओआरएम ढांचे और पुस्तकालयों के प्रसार में "मदद करना"। उनका उपयोग करते हुए, डेटाबेस एक्सेस सेवाओं के कई डेवलपर्स अनुरोध के परिणामस्वरूप अनजाने में संभव वस्तुओं के रूप में उच्च देना चाहते हैं। एक विशिष्ट उदाहरण उपयोगकर्ता डेटा के लिए एक ग्रीटिंग में या प्रमाणीकरण परिणाम के साथ क्षेत्र में प्रदर्शित करने के लिए अनुरोध है। तीन टेक्स्ट वेरिएबल्स (first_name, mid_name, last_name) के रूप में उपयोगकर्ता नाम वापस करने के बजाय, ऐसा अनुरोध अक्सर दर्जनों विशेषताओं और कनेक्टेड ऑब्जेक्ट्स के साथ एक पूर्ण-उपयोगकर्ता उपयोगकर्ता ऑब्जेक्ट लौटाता है, जैसे अनुरोधित उपयोगकर्ता की भूमिकाओं की सूची। यह बदले में, अनुरोध के परिणाम को संसाधित करने के तर्क को उलझा देता है, लौटे ऑब्जेक्ट के प्रकार पर हैंडलर की अनावश्यक निर्भरता उत्पन्न करता है और ... - इस सेवा ऑब्जेक्ट के लिए जिम्मेदार बाहरी से जुड़े तर्क को लागू करने की संभावना के कारण जिम्मेदारी का एक धब्बा साबित करता है।

क्या करें? (संदर्भ)

काश, कुछ मामलों में ज़िम्मेदारी का हनन कभी-कभी मजबूर और कभी-कभी न्यायसंगत भी होता है।

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

ठीक है, अगर एक प्रणाली में कतिपय वस्तुओं पर कड़ाई से संचालन को केंद्रित करना असंभव है, तो इस तरह के धब्बा को सिस्टम-वाइड ("सुपरकंपोनेंट") प्रलेखन में डेटा तत्व, डोमेन ऑब्जेक्ट पर या एक दूसरे पर घटकों की विशिष्ट निर्भरता के रूप में बहुत सावधानी से दर्ज किया जाना चाहिए।

इस मामले पर आपकी राय जानना दिलचस्प होगा और साथ ही इस लेख के शोधों की पुष्टि या खंडन करने वाले मामलों से भी।

लेख को अंत तक पढ़ने के लिए धन्यवाद।

लेख के लेखक द्वारा चित्रण "मल्टीमीडिया मिखेर"।

उन त्रुटियों के बारे में जो कहीं से भी नहीं निकलती हैं और जिसमें कोई भी दोषी नहीं है: जिम्मेदारी के धब्बा की घटना

अवलोकन और विचार

क्या करें? (संदर्भ)

More articles: