DRuby उर्फ ​​DRb - रूबी में वितरित सिस्टम का आधार। काम और पिटने का सिद्धांत

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

मान लीजिए आप एक ऐसी प्रणाली लिख रहे हैं जो एक से अधिक प्रक्रियाओं के साथ काम करती है। उदाहरण के लिए, आपके पास एक वेब सर्वर है जो पृष्ठभूमि में लंबे समय तक चलने वाले कार्यों को चलाता है। या आपको बस एक प्रक्रिया से दूसरी प्रक्रिया में डेटा के हस्तांतरण को सुनिश्चित करने और उन्हें समन्वयित करने की आवश्यकता है। ऐसी स्थितियों के लिए, आपको DRB लाइब्रेरी की आवश्यकता है। यह पूरी तरह से रूबी में लिखा गया है और मानक पुस्तकालय में शामिल है, इसलिए आप इसके साथ तुरंत काम करना शुरू कर सकते हैं। इसे जोड़ने के लिए, बस require 'drb' लिखना होगा

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

यह सत्यापित करने के लिए कि सब कुछ काम करता है, दो irb टर्मिनल खोलें। मैं स्वीकार करता हूं कि मुझे नहीं पता कि रूबी 1.8 में कितने बड़े अंतर हैं, तो चलिए सहमत हैं कि हम संस्करण 1.9 पर चर्चा कर रहे हैं (विशेष रूप से 1.8 के बाद से - जल्द ही समर्थन करने के लिए बंद हो जाएगा, हुर्रे!)

सशर्त रूप से, ये दो टर्मिनल एक सर्वर और एक क्लाइंट हैं। सर्वर को एक फ्रंट ऑब्जेक्ट प्रदान करना होगा जो अनुरोध प्राप्त करेगा। यह ऑब्जेक्ट कोई भी वस्तु हो सकती है: यहां तक ​​कि एक निर्मित प्रकार की एक वस्तु, यहां तक ​​कि एक विशेष रूप से बनाए गए इंटरफ़ेस के साथ एक मॉड्यूल भी। बदले में, क्लाइंट सर्वर से जुड़ता है और इस ऑब्जेक्ट के साथ इंटरैक्ट करता है।
उदाहरण के लिए, चलिए पहले टर्मिनल में सर्वर शुरू करते हैं और एक साधारण एरे डालते हैं।

 require 'drb' front = [] DRb.start_service('druby://localhost:1234', front) front << 'first' #       ,    -    DRb.thread.join 

अब क्लाइंट को कनेक्ट करें। हम एरे के पहले एलीमेंट को पहचानते हैं और एरे को दूसरे एलीमेंट लिखते हैं

 require 'drb' DRb.start_service remote_obj = DRbObject.new_with_uri('druby://localhost:1234') p remote_obj p remote_obj[0] remote_obj << 'second' 

अब आप पहले टर्मिनल से front[1] कॉल कर सकते हैं और देख सकते हैं कि स्ट्रिंग 'second' । और आप किसी अन्य क्लाइंट को कनेक्ट कर सकते हैं, और इससे उसी ललाट ऑब्जेक्ट पर भी काम करते हैं।

जैसा कि आपने पहले ही देखा है, सर्वर की शुरुआत DRb.start_service कमांड द्वारा की DRb.start_service (रजिस्टर पर नजर रखें)। विधि एक तर्क के रूप में लेती है जिसमें 'druby://hostname:port' और फ्रंट-एंड ऑब्जेक्ट के पते के साथ एक स्ट्रिंग होती है। एक फ्रंट-एंड ऑब्जेक्ट एक ऑब्जेक्ट है जिसे अनुरोध प्राप्त होंगे।
जब सर्वर एक अलग स्क्रिप्ट में शुरू होता है, तो स्क्रिप्ट के अंत में DRb.thread.join लिखें। तथ्य यह है कि DRb सर्वर एक अलग थ्रेड में लॉन्च किया गया है, और रूबी मुख्य धागा पूरा होते ही प्रोग्राम को बंद कर देता है। इसलिए, यदि मुख्य थ्रेड डीआरबी सर्वर स्ट्रीम के बंद होने का इंतजार नहीं करता है, तो दोनों धाराएं अनुसूची से पहले पूरी हो जाएंगी, और सर्वर तुरंत अनुपलब्ध हो जाएगा। इस तथ्य के लिए तैयार रहें कि सर्वर बंद होने तक DRb.Thread.join विधि का निष्पादन वर्तमान थ्रेड को ब्लॉक करता है।

सर्वर से कनेक्ट करने के लिए, आपको DRbObject.new_with_uri विधि को कॉल करना DRbObject.new_with_uri और उस पते को पास करना होगा जहां सर्वर एक तर्क के रूप में शुरू होता है। यह विधि remote_obj प्रॉक्सी ऑब्जेक्ट लौटाएगा। प्रॉक्सी ऑब्जेक्ट के लिए अनुरोध (विधि कॉल) स्वचालित रूप से दूरस्थ सर्वर पर ऑब्जेक्ट को स्थानांतरित कर दिया जाता है, कहा जाता है कि विधि वहां निष्पादित होती है, और फिर परिणाम को कॉल करने वाले क्लाइंट को वापस कर दिया जाता है। (हालाँकि, सभी तरीकों को सर्वर पर नहीं बुलाया जाता है। उदाहरण के लिए, व्यवहार को देखते हुए, #class विधि #class स्थानीय रूप #class निष्पादित किया जाता है)
क्लाइंट थोड़ी देर बाद DRb.start_service कमांड DRb.start_service अर्थ DRb.start_service करेगा।

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

लेकिन इतना सरल नहीं है। रिमोट विधि मंगलाचरण महंगा है। कल्पना करें कि एक सर्वर पर एक विधि बहुत सारे तर्क विधियों को "खींचती है"। इसका मतलब यह होगा कि सर्वर और क्लाइंट, गणना करने के बजाय, समय के शेर का हिस्सा अपेक्षाकृत धीमी प्रोटोकॉल का उपयोग करके एक-दूसरे तक पहुंचेंगे (और यह अच्छा है अगर दोनों प्रक्रियाएं एक ही मशीन पर स्थित हैं)। इसे रोकने के लिए, तर्क और प्रक्रियाओं के बीच के परिणाम को मान से पारित किया जाता है, संदर्भ से नहीं (ऑब्जेक्ट का मार्शलाइज़ेशन केवल ऑब्जेक्ट की आंतरिक स्थिति को बताता है और इसके ऑब्जेक्ट_ड को नहीं जानता है - इसलिए ऑब्जेक्ट को पहले अनुक्रमित किया जाएगा, और उसके बाद deserialized केवल मूल ऑब्जेक्ट की एक प्रति होगी। लेकिन एक ही वस्तु द्वारा नहीं, इसलिए स्थानांतरण स्वचालित रूप से प्रतिलिपि द्वारा किया जाता है)। रूबी में, आमतौर पर सब कुछ संदर्भ द्वारा पारित किया जाता है, और dRuby में, आमतौर पर मूल्य द्वारा। इस प्रकार, यदि आप front[0].upcase! सर्वर पर, तो front[0] का मान front[0] बदल जाएगा, और यदि आप remote_obj[0].upcase! निष्पादित remote_obj[0].upcase! , तब आपको ऊपरी मामले में पहला तत्व मिलेगा, लेकिन remote_obj.[](0) बाद से सर्वर पर मूल्य नहीं बदलेगा remote_obj.[](0) पहले तत्व की एक प्रति है। इस कॉल को front[0].dup.upcase! समान माना जा सकता है front[0].dup.upcase!
हालाँकि, आप हमेशा dRuby के व्यवहार को इस तरह से परिभाषित कर सकते हैं जैसे कि तर्क और संदर्भ द्वारा परिणाम, लेकिन बाद में और अधिक।

अब पहली समस्या के बारे में बात करने का समय है। सभी वस्तुओं को मार्शलाइज़ नहीं किया जाता है। उदाहरण के लिए, प्रोक और आईओ ऑब्जेक्ट्स, साथ ही थ्रेड्स (थ्रेड ऑब्जेक्ट्स) को कॉपी पर मार्श किया और प्रसारित नहीं किया जा सकता है। dRuby इस मामले में आगे बढ़ता है: यदि मार्शलाइजेशन काम नहीं करता है, तो ऑब्जेक्ट को संदर्भ से पारित किया जाता है।
तो, संदर्भ द्वारा वस्तु को कैसे पारित किया जाता है? सी याद करो। वहां, इस उद्देश्य के लिए पॉइंटर्स का उपयोग किया जाता है। रूबी में, सूचक की भूमिका object_id द्वारा की जाती है। किसी ऑब्जेक्ट को संदर्भ द्वारा पास करने के लिए, DRbObject क्लास की ऑब्जेक्ट का DRbObject ।
DRbObject , वास्तव में, संदर्भ द्वारा पारित करने के लिए एक प्रॉक्सी वस्तु है। इस श्रेणी के एक उदाहरण DRbObject.new(my_obj) में ऑब्जेक्ट my_obj object_id ऑब्जेक्ट_ my_obj और सर्वर का URI होता है जहां ऑब्जेक्ट आया था। यह आपको विधि कॉल को इंटरसेप्ट करने और रिमोट मशीन (या किसी अन्य टर्मिनल) पर बहुत ही ऑब्जेक्ट को पास करने की अनुमति देता है जिसमें विधि का इरादा था।

चलो हमारे सर्वर को एक विधि बनाते हैं

 def front.[](ind) DRbObject.new(super) end 

और क्लाइंट से कोड चलाएं।

 remote_obj.[0].upcase! 

नई विधि #[] पहले तत्व की एक प्रति नहीं upcase! , लेकिन एक लिंक है, इसलिए upcase! विधि को निष्पादित करने के बाद upcase! सामने की वस्तु बदल गई है, इसे निष्पादित करके सत्यापित करना आसान है, उदाहरण के लिए, क्रमशः क्लाइंट और सर्वर से, puts remote_obj puts front या puts front कमांड puts front है।

लेकिन हर बार मैं DRbObject.new - आलस्य लिखता DRbObject.new । सौभाग्य से, मूल्य के बजाय संदर्भ द्वारा किसी वस्तु को पारित करने का एक और तरीका है। ऐसा करने के लिए, यह ऑब्जेक्ट को गैर-मार्शल करने योग्य बनाने के लिए पर्याप्त है। यह करना आसान है, बस ऑब्जेक्ट में DRbUndumped मॉड्यूल शामिल करें।

 my_obj.extend DRbUndumped class Foo; include DRbUndumped; end 

अब ऑब्जेक्ट my_obj और Foo वर्ग की सभी वस्तुएं स्वचालित रूप से संदर्भ (और Marshal.dump(my_obj) TypeError 'can\'t dump' ) द्वारा पारित हो जाएंगी।

मैं एक उदाहरण देता हूं जो मुझे अभ्यास में मिला था। सर्वर हैश को सामने की वस्तु के रूप में सेट करता है, जिसमें मान टिकट होते हैं (टिकट के अंदर से एक राज्य मशीन है)। तब remote_obj[ticket_id] टिकट की एक प्रति देता है। लेकिन यह हमें केवल स्थानीय स्तर पर सर्वर पर टिकट की स्थिति बदलने की अनुमति नहीं देता है। आइए, DRbUndumped को Ticket क्लास में DRbUndumped । अब हम टिकट की एक प्रति नहीं हैश से प्राप्त करते हैं, लेकिन इसके लिए एक लिंक - और इसके साथ कोई भी क्रिया अब क्लाइंट पर नहीं, बल्कि सर्वर पर होती है।

और अब यह वादा के बारे में याद रखने का समय है और हमें बताएं कि आपको क्लाइंट पर DRb.start_service को कॉल करने की आवश्यकता क्यों है। कल्पना करें कि एक सरणी आपके सर्वर पर सामने की वस्तु द्वारा इंगित की गई है, जैसा कि पहले उदाहरण में है।
अब क्लाइंट को remote_obj.map{|x| x.upcase} विधि को कॉल करने दें remote_obj.map{|x| x.upcase} remote_obj.map{|x| x.upcase}
वास्तव में, ब्लॉक तर्क के साथ नक्शा विधि को सामने की वस्तु पर कहा जाता है। और हम, जैसा कि हम याद करते हैं, मार्श नहीं किया जा सकता है। तो यह ब्लॉक तर्क संदर्भ द्वारा पारित किया जाता है। सर्वर पर map विधि इसे yield साथ एक्सेस करेगी, जिसका अर्थ है कि क्लाइंट सर्वर है! लेकिन चूँकि क्लाइंट को समय-समय पर सर्वर बनना होता है, इसका मतलब है कि उसे DR_ सर्वर को भी start_service पद्धति का उपयोग करके शुरू करना है। इस सर्वर के यूआरआई को निर्दिष्ट करना आवश्यक नहीं है। यह अंदर से कैसे काम करता है, मुझे नहीं पता, लेकिन यह काम करता है। और जैसा कि आपने पहले ही देखा है, क्लाइंट और सर्वर के बीच अंतर कम से कम यह लग सकता है।

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

 Ticket.send :include, DRbUndumped def front.get_ticket Ticket.new end foo = remote_obj.get_ticket foo.start foo.closed? #   foo       . ,   start   . 

इसे इस तरह लिखा जाना चाहिए:

 Ticket.send :include, DRbUndumped def front.get_ticket object_to_reference = Ticket.new yield object_to_reference end remote_obj.get_ticket do |foo| foo.start foo.closed? end 

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

 require 'drb/timeridconv' DRb.install_id_conv(DRb::TimerIdConv.new) 

सर्वर शुरू करने से पहले। अधिक जानकारी के लिए, पुस्तक का अध्याय 11 देखें - कचरा संग्रहण संभालना। यह मुझे दिलचस्प लगता है, और शायद इसे पढ़ने के बाद आपके पास कचरा संग्रहण प्रक्रिया के हेरफेर का उपयोग करने के नए तरीके होंगे। लेकिन फिर भी, मुझे लगता है कि व्यवहार में दूसरी विधि का उपयोग करना बेहतर है - और ब्लॉक को लिंक देना। अधिक विश्वसनीय और समझ में आता है।

यह प्रकाशमान रहता है, शायद, आखिरी क्षण। मान लीजिए कि आप एक लिंक के रूप में एक Foo ऑब्जेक्ट पास करते हैं। ग्राहक किसी भी Foo वर्ग के बारे में नहीं जानता है, और फिर भी यह ऑब्जेक्ट के साथ काम करने से नहीं रोकता है। संक्षेप में, क्लाइंट DRbObject क्लास के ऑब्जेक्ट के साथ संचालित होता है। सब कुछ हमेशा की तरह है।
अब कल्पना करें कि आप लिंक नहीं, बल्कि एक प्रति प्रेषित कर रहे हैं। सर्वर पर क्रमांकन ने वस्तु की स्थिति और उसकी कक्षा के नाम को बचाया। क्लाइंट को स्ट्रिंग प्राप्त हुआ और वह इसे डीरिशियल करने की कोशिश कर रहा है। बेशक, यह उसके लिए काम नहीं करता है, क्योंकि क्लाइंट कोई भी वर्ग Foo की ऑब्जेक्ट नहीं बना सकता है। तब deserialization DRb::DRbUnknown प्रकार की एक वस्तु DRb::DRbUnknown , जो DRb::DRbUnknown ऑब्जेक्ट के साथ एक बफर स्टोर करेगा। इस ऑब्जेक्ट को (उदाहरण के लिए, कार्य कतार में) पास किया जा सकता है। आप कक्षा के नाम का भी पता लगा सकते हैं, कक्षा के साथ उपयुक्त पुस्तकालय लोड कर सकते हैं, और reload से reload करने की विधि को कॉल कर सकते हैं - फिर एक और प्रयास deserialize करने के लिए किया जाएगा। यह है

नहीं, अभी भी यह अंतिम क्षण नहीं है। मैंने सिंक्रनाइज़ेशन के बारे में नहीं लिखने का वादा किया था, लेकिन फिर भी मैं कुछ शब्द नहीं कहूंगा।
वितरित प्रोग्रामिंग के लिए, क्रियाओं का सिंक्रनाइज़ेशन और संचालन की परमाणुता महत्वपूर्ण अवधारणाएं हैं। सर्वर एक अलग थ्रेड में शुरू होता है। और सर्वर के लिए प्रत्येक अनुरोध के लिए, एक अलग स्ट्रीम स्वचालित रूप से बनाई जाती है जिसमें यह अनुरोध संसाधित होता है। इसलिए यह आवश्यक है कि एक ही समय पर एक ही सूचना पर विभिन्न थ्रेड्स को प्रतिबंधित किया जाए। इसलिए जब प्रोग्रामिंग वितरित और समानांतर सिस्टम का उपयोग करें:
1) निर्माण lock = Mutex.new; lock.synchronize{ do_smth } lock = Mutex.new; lock.synchronize{ do_smth }
मानक MonitorMixin लाइब्रेरी के 2) मॉड्यूल
3) Queue मानक पुस्तकालय कक्षाएं, SizedQueue

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