ErlyBank को बचाए रखने के लिए नियंत्रकों का उपयोग करना

ओटीपी श्रृंखला के परिचय में यह चौथा लेख है। यदि आप अभी हमारे साथ आए हैं , तो मैं पहले भाग से शुरू करने की सलाह देता हूं, जो gen_server के बारे में बात करता है और हमारी बैंकिंग प्रणाली की नींव रखता है। यदि आप एक सक्षम छात्र हैं, तो आप वर्तमान में तैयार मॉड्यूल पर एक नज़र डाल सकते हैं: eb_server.erl , eb_event_manager.erl , eb_withdrawal_handler.erl और eb_atm.erl ।

परिदृश्य : जिस क्षण को हम बैंकों और एटीएम में पसंद करते हैं, वह यह है कि वे हमेशा एक ही स्थान पर होते हैं। एटीएम का उपयोग करके, हम जब चाहें, 24 घंटे एक दिन में पैसे निकाल या जमा कर सकते हैं। या जब यह खुला हो तो बैंक की किसी भी शाखा में जाएं, यह जानते हुए कि हमारे पास अपने वित्त की पूरी पहुंच होगी। इसकी गारंटी देने के लिए, आपको यह सुनिश्चित करने की आवश्यकता है कि हमारी ErlyBank स्वचालन प्रणाली हमेशा चालू रहती है: प्रक्रियाओं को लगातार चलना चाहिए। ErlyBank ने हमें इस लक्ष्य को महसूस करने का निर्देश दिया। एक सौ प्रतिशत uptime! (या जितना हम प्रदान कर सकते हैं)

परिणाम : ओटीपी पर्यवेक्षक का उपयोग करके, हम एक प्रक्रिया बनाएंगे जिसकी जिम्मेदारी चल रही प्रक्रियाओं की निगरानी करना और यह सुनिश्चित करना है कि वे सक्रिय हैं।

नियंत्रक क्या है?

एक नियंत्रक एक प्रक्रिया है जो उस प्रक्रिया को ट्रैक करती है जिसे बाल प्रक्रिया कहा जाता है। यदि बच्चा प्रक्रिया "उड़ा दी जाती है", तो नियंत्रक इस बच्चे की पुनरारंभ रणनीति को पुनः आरंभ करने के लिए उपयोग करता है। यह विधि एर्लांग प्रणालियों की सतत उपलब्धता सुनिश्चित कर सकती है।

एक नियंत्रक एक हिस्सा है जिसे पर्यवेक्षण वृक्ष कहा जाता है। एक अच्छी तरह से लिखा गया एर्लांग / ओटीपी एप्लिकेशन रूट कंट्रोलर से शुरू होता है, जो बाल नियंत्रकों की निगरानी करता है, जो बदले में अतिरिक्त नियंत्रकों या प्रक्रियाओं की निगरानी करता है। विचार यह है कि यदि नियंत्रक क्रैश हो जाता है, तो मूल नियंत्रक इसे पुनरारंभ करता है, और इसी तरह रूट कंट्रोलर तक। Erlang रनटाइम में एक उत्कृष्ट मोड होता है जिसमें पूरे सिस्टम की निगरानी की जाती है और रूट कंट्रोलर की मृत्यु हो जाती है। इस प्रकार, नियंत्रण पेड़ हमेशा चालू रहेगा।

नियंत्रक में केवल एक प्रतिक्रिया विधि है : init / 1 । इसका कार्य बाल प्रक्रियाओं की एक सूची को वापस करना और प्रत्येक प्रक्रिया के लिए रणनीतियों को फिर से शुरू करना है, ताकि नियंत्रक को पता चल जाए कि क्या गलत है और क्या करना है।

अलग-अलग eb_server और इवेंट मैनेजर

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

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

init([]) ->
eb_event_manager:add_handler(eb_withdrawal_handler),
{ok, dict:new()}.

अपने परिवर्तनों के बाद eb_server.erl देखने के लिए यहां क्लिक करें ।

नियंत्रक फ्रेम

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

वायरफ्रेम को eb_sup.erl के रूप में सहेजें। इस फ़ाइल का नामकरण एक और सम्मेलन है। किसी विशेष समूह के नियंत्रक में हमेशा " _sup " प्रत्यय होता है । यह एक आवश्यकता नहीं है, लेकिन मानक अभ्यास है।

रणनीतियों को फिर से शुरू करें

नियंत्रक के पास एक एकल पुनरारंभ रणनीति है, जिसका उपयोग यह निर्धारित करने के लिए वंशज विनिर्देशों के साथ संयोजन में करता है कि क्या उसके वंश में से एक मर जाएगा। निम्नलिखित सूची में संभावित पुनरारंभ रणनीतियाँ हैं:

• one_for_one - जब बच्चा प्रक्रिया में से किसी एक की मृत्यु हो जाती है, तो नियंत्रक इसे पुनः आरंभ करता है। अन्य वंशज स्पर्श नहीं करते हैं।
• one_for_all - जब बच्चे की प्रक्रिया में से एक की मृत्यु हो जाती है, तो अन्य सभी बच्चे बंद हो जाएंगे और फिर सभी पुनरारंभ हो जाएंगे।
• rest_for_one - जब बच्चा प्रक्रिया में से एक की मृत्यु हो जाती है, तो मृतक के पूरा होने के बाद वंश के विनिर्देशों की सूची में परिभाषित वंश के "शेष", जिसके बाद वे सभी फिर से शुरू होते हैं।

पुनरारंभ की रणनीति निम्न प्रारूप में इंगित की गई है:

{RestartStrategy, MaxRetries, MaxTime}

यह समझना बहुत आसान है, रूसी में बोलना: यदि बच्चे को मैक्सटाइम सेकंड्स में एक बार मैक्सट्रेट्स की तुलना में अधिक बार पुनरारंभ किया जाता है, तो नियंत्रक सभी बच्चे की प्रक्रियाओं को समाप्त कर देता है और फिर खुद काम करना बंद कर देता है। यह बच्चे के पुनरारंभ के एक अंतहीन लूप को रोकने के लिए किया जाता है।

वंशज विनिर्देश के सिंटेक्स और बुनियादी अवधारणाओं

नियंत्रक इनिट विधि वंशज विनिर्देशों की सूची वापस करने के लिए जिम्मेदार है। ये विनिर्देश नियंत्रक को बताते हैं कि कौन सी प्रक्रिया शुरू करनी है और यह कैसे करना है। नियंत्रक प्रक्रिया को "बाएं से दाएं" (सूची की शुरुआत से लेकर उसके अंत तक) क्रम में शुरू करता है। पुनः आरंभ करने की रणनीति निम्नलिखित प्रारूप के साथ एक समस्या है:

{Id, StartFunc, Restart, Shutdown, Type, Modules}

:
Id = term()
StartFunc = {M,F,A}
M = F = atom()
A = [term()]
Restart = permanent | transient | temporary
Shutdown = brutal_kill | int()>=0 | infinity
Type = worker | supervisor
Modules = [Module] | dynamic
Module = atom()


वंश के विनिर्देशन को संग्रहीत करने के लिए आईडी का उपयोग केवल नियंत्रक के अंदर किया जाता है, लेकिन सामान्य सम्मेलन में मॉड्यूल नाम का उपयोग आईडी के रूप में किया जाता है, जब तक कि आप मॉड्यूल के कई उदाहरण नहीं चला रहे हों; उत्तरार्द्ध मामले में, आईडी में एक संख्या जोड़ें।

StartFunc प्रारूप {मॉड्यूल, फंक्शन, आर्ग्स} में एक टपल है, जो उस फ़ंक्शन को इंगित करता है जिसके मंगलाचरण की प्रक्रिया शुरू होती है। बहुत महत्वपूर्ण : प्रारंभ फ़ंक्शन को प्रक्रिया शुरू करनी चाहिए और इसे लिंक करना चाहिए और {ok, Pid} , {ok, Pid, ​​Other} या {error, Reason} को वापस करना चाहिए। पारंपरिक ओटीपी स्टार्ट_लिंक विधियां इस नियम का पालन करती हैं। लेकिन अगर आप एक मॉड्यूल लागू कर रहे हैं जो अपनी प्रक्रियाएं शुरू करता है, तो उन्हें शुरू करने के लिए स्पॉन_लिंक का उपयोग करना सुनिश्चित करें ।

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

शटडाउन नियंत्रक को समझाता है कि बाल प्रक्रियाओं को कैसे समाप्त किया जाए। Brutal_kull परमाणु अपनी समाप्ति पद्धति को लागू किए बिना बच्चे को समाप्त करता है। शून्य से ऊपर कोई भी पूर्णांक सही पूर्णता के लिए एक समय सीमा निर्धारित करता है। परमाणु " अनन्तता " प्रक्रिया को विनम्रता से पूरा करेगा और इसके हमेशा के लिए रुकने का इंतजार करेगा।

प्रकार नियंत्रक को बताता है कि वंश क्या है: एक अन्य नियंत्रक या कोई अन्य प्रक्रिया। यदि यह एक नियंत्रक है, तो पर्यवेक्षक परमाणु का उपयोग करें, अन्यथा कार्यकर्ता परमाणु का उपयोग करें।

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

वाह! इतने कम समय में सीखने के लिए इतनी जानकारी। वंशज विनिर्देशों और विभिन्न पुनरारंभ रणनीतियों के प्रारूप को याद करने के लिए मुझे काफी समय लगा, इसलिए चिंता न करें अगर आप इसे तुरंत नहीं कर सकते हैं। आप हमेशा कंट्रोलर मैनुअल में जानकारी को रिफ्रेश कर सकते हैं।

इवेंट मैनेजर वंशज कल्पना

शुरू करने के लिए पहली बात एक घटना प्रबंधक है, क्योंकि सर्वर इस पर निर्भर करता है। वंशज विनिर्देश कुछ इस तरह दिखता है:

EventManager = {eb_event_manager,{eb_event_manager, start_link,[]},
permanent,2000,worker,dynamic}.

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

यहाँ वंशावली ऐनक सहित प्रारंभिक विधि है:

init([]) ->
EventManager = {eb_event_manager,{eb_event_manager, start_link,[]},
permanent,2000,worker,dynamic},
{ok,{{one_for_one,5,10}, [EventManager]}}.

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

यदि आप अब नियंत्रक को संकलित करते हैं और चलाते हैं (मुझे लगता है कि यह इसके लायक है!), तो नियंत्रक से संबंधित start_link विधि शुरू करने के बाद, जहाँ (eb_event_manager) दर्ज करें, और कमांड को इवेंट मैनेजर प्रक्रिया के पहचानकर्ता ( pid ) को वापस करना चाहिए। फिर, यदि आप एक्जिट को निष्पादित करते हुए कंट्रोलर को मारते हैं (जहाँ (eb_sup), मारते हैं) , और फिर eb_event_manager पहचानकर्ता को फिर से प्राप्त करने का प्रयास करें, आपको प्रतिक्रिया में एक संदेश प्राप्त करना चाहिए कि यह परिभाषित नहीं था, क्योंकि प्रक्रिया को मार दिया गया था।

इसके अलावा, मज़े के लिए, नियंत्रक के नियंत्रण में काम करते हुए eb_event_manager को मार दें। कुछ सेकंड प्रतीक्षा करें और प्रक्रिया की जाँच करें। उसे ठीक होना चाहिए!

सर्वर और ए.टी.एम.

वंश के विनिर्देश और ऊपर दिए गए उदाहरण की मदद से, आपको सर्वर और बैंक शुरू करने के लिए पर्याप्त पता होना चाहिए। तो अगर आपको लगता है कि चुनौती आपको लुभा रही है, तो अभी करें। यदि नहीं, तो मैंने नीचे उन दोनों के लिए विशिष्टताओं का हवाला दिया है:

Server = {eb_server, {eb_server, start_link, []},
permanent,2000,worker,[eb_server]},
ATM = {eb_atm, {eb_atm, start_link, []},
permanent,2000,worker,[eb_atm]},


इन विशिष्टताओं को बनाने के बाद, उन्हें आरंभिक विधि द्वारा लौटी सूची में जोड़ें। इवेंट मैनेजर के बाद उन्हें रखना सुनिश्चित करें।

आप यहां क्लिक करके पूरा किया गया eb_sup.erl देख सकते हैं।

रनटाइम पर बच्चों को जोड़ना और निकालना

दुर्भाग्य से, मैं इस तंत्र को ErlyBank में सम्मिलित करने के लिए एक मजाकिया स्क्रिप्ट के साथ नहीं आ सका, लेकिन मुझे लगा कि start_child और delete_dild तरीकों का उपयोग करके पहले से चल रहे नियंत्रक प्रक्रिया में बच्चे के विनिर्देशों को गतिशील रूप से जोड़ने और निकालने की क्षमता को नोट करना महत्वपूर्ण था।

वे काफी सरल हैं, इसलिए मैंने यहां बताए गए गाइड को नहीं दोहराया; आप सीधे इसमें जा सकते हैं और इन तरीकों से खुद को परिचित कर सकते हैं।

निष्कर्ष

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

यह इरलंग / OTP श्रृंखला के परिचय में चौथा लेख समाप्त करता है। पांचवां लेख तैयार है, अगले कुछ दिनों में प्रकाशन के लिए निर्धारित है और आवेदन प्रस्तुत करेगा।

---

श्रृंखला के लेख

4. ErlyBank को बनाए रखने के लिए नियंत्रकों का उपयोग करना (वर्तमान लेख)
3. gen_event का परिचय: चालान में परिवर्तन की सूचनाएँ

अनुवाद का लेखक tiesto है :
2. gen_fsm का परिचय: ErlyBank ATM
1. gen_server का परिचय: ErlyBank
0. ओपन टेलिकॉम प्लेटफॉर्म / ओपन टेलीकम्यूनिकेशन प्लेटफॉर्म (OTP / OTP) का परिचय
-1। प्रागितिहास