Gen_event का परिचय: खाता परिवर्तन अधिसूचनाएँ

अनुवादक से: मैं कर्म की कमी के कारण ध्वज फेंकने वाले तिपतिया को पकड़ने की कोशिश करूँगा (वैसे, पहले अनुवाद के लिए उसे बहुत धन्यवाद; यह उनके लिए धन्यवाद था कि मैंने लेखक के बारे में सीखा है, जिनके लेखों की श्रृंखला मैं अनुवाद जारी रखना चाहता हूं)।

पिछले भागों के लिंक लेख के अंत में पाए जा सकते हैं।

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

परिदृश्य : केंद्रीय सर्वर सॉफ्टवेयर और स्थानीय एटीएम के आगमन के साथ, ErlyBank ने अपने तकनीकी आधार को आशावादी रूप से समझना शुरू कर दिया। लेकिन प्रतियोगियों में से एक के खिलाफ सुरक्षा के साधन के रूप में, वे एक ऐसी प्रणाली को लागू करना चाहेंगे जो एक निश्चित मात्रा में नकदी वापस लेने पर सूचनाएं भेजती है। वे नकदी निकासी राशि की सीमा मूल्य को बदलने में सक्षम होना चाहते हैं, जिसके बाद सॉफ्टवेयर को रिबूट किए बिना एक अधिसूचना चालू हो जाती है। प्रबंधन ने हमें कार्य के अनुसार वर्तमान संस्करण को अपग्रेड करने के लिए नियुक्त करने का निर्णय लिया।

परिणाम : हम gen_event का उपयोग करके एक इवेंट-आधारित सूचना प्रणाली बनाएंगे । यह हमें भविष्य में अन्य सूचनाएं बनाने के लिए एक मूल आधार देगा, जबकि एक ही समय में वर्तमान सर्वर सॉफ़्टवेयर में एकीकृत करना आसान बनाता है।

Gen_event क्या है?

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

हैंडलर के लिए अपेक्षित कॉलबैक हैं:

• init / 1 - एक हैंडलर को प्रारंभ करता है।
• handle_event / 2 - इवेंट मैनेजर को भेजे गए किसी भी इवेंट को हैंडल करता है जिसे श्रोता सुनता है।
• handle_call / 2 - एक इवेंट को हैंडल करता है जिसे इवेंट मैनेजर को कॉल के रूप में भेजा जाता है। इस संदर्भ में एक कॉल gen_server के व्यवहार में कॉल के समान है: जब तक कोई जवाब नहीं भेजा जाता तब तक निष्पादन निलंबित है।
• handle_info / 2 - हैंडलर को भेजे गए किसी भी संदेश को संभालता है जो एक ईवेंट (ईवेंट) या कॉल (कॉल) नहीं है।
• समाप्त / 2 - जब हैंडलर बाहर निकलता है तो कॉल किया जाता है ताकि प्रक्रिया किसी भी संसाधन को मुक्त कर सके।
• code_change / 3 - कॉल किया जाता है जब मॉड्यूल ऑपरेशन के दौरान सीधे एक कोड परिवर्तन से गुजरता है। यह मोड इस लेख में वर्णित नहीं है, लेकिन इस श्रृंखला के भविष्य के लेखों में से एक का नायक होगा।

इस श्रृंखला में पहले वर्णित दो व्यवहार मॉड्यूल की तुलना में, वर्तमान में प्रतिक्रिया विधियों की अपेक्षाकृत कम संख्या है। हालाँकि, gen_event को अक्सर ही इस्तेमाल किया जा सकता है और इसमें अन्य OTP मॉड्यूल की तुलना में कोई कम सुविधाएँ नहीं हैं।

इवेंट मैनेजर बनाएं

घटना प्रबंधक बनाने के लिए सबसे पहली चीज जो हमें करने की आवश्यकता है। यह एक अपेक्षाकृत सरल कार्य है, क्योंकि यह केवल gen_event सर्वर को शुरू करता है, और शीर्ष पर कुछ एपीआई तरीकों को जोड़कर, नए हैंडलर जोड़ना, सूचनाएं भेजना आदि आसान है।

मेरे इवेंट मैनेजर ढांचे पर एक नज़र डालें। इसके अलावा, मैं इसे आधार के रूप में उपयोग करते हुए, टुकड़े दूँगा।

जैसा कि आप देख सकते हैं, फ़ाइल असामान्य नहीं है। प्रारंभिक विधि अन्य ओटीपी व्यवहार मॉड्यूल के समान है। मैंने इवेंट मैनेजर में हैंडलर जोड़ने के लिए मुख्य एपीआई को शामिल किया है:
%%--------------------------------------------------------------------
%% Function: add_handler(Module) -> ok | {'EXIT',Reason} | term()
%% Description: Adds an event handler
%%--------------------------------------------------------------------
add_handler(Module) ->
gen_event:add_handler(?SERVER, Module, []).

यह विधि बस एक इवेंट हैंडलर को वर्तमान मॉड्यूल में स्थित इवेंट मैनेजर में जोड़ती है। मैंने इवेंट मैनेजर के माध्यम से एक अधिसूचना भेजने के लिए एक आसान-से-उपयोग विधि भी जोड़ा,:
%%--------------------------------------------------------------------
%% Function: notify(Event) -> ok | {error, Reason}
%% Description: Sends the Event through the event manager.
%%--------------------------------------------------------------------
notify(Event) ->
gen_event:notify(?SERVER, Event).

इसे समझना भी काफी आसान होना चाहिए। विधि बस इवेंट मैनेजर को इवेंट भेजती है। gen_event: सूचित / 2 एक अतुल्यकालिक अनुरोध है, इसलिए एक वापसी तुरंत होगी।

इवेंट मैनेजर को सर्वर से जोड़ना

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

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


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

handle_call({withdraw, Name, Amount}, _From, State) ->
case dict:find(Name, State) of
{ok, {_PIN, Value}} when Value < Amount ->
{reply, {error, not_enough_funds}, State};
{ok, {PIN, Value}} ->
NewBalance = Value - Amount,
NewState = dict:store(Name, {PIN, NewBalance}, State),
% Send notification
eb_event_manager:notify({withdraw, Name, Amount, NewBalance}),
{reply, {ok, NewBalance}, NewState};
error ->
{reply, {error, account_does_not_exist}, State}
end;


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

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

Eb_server.erl की सभी सामग्री यहाँ देखी जा सकती है ।

हैंडलर फ्रेम

मेरे पास सभी ओटीपी मॉड्यूल के लिए एक बुनियादी ढांचा है जो मैं हमेशा से शुरू करता हूं। वह इवेंट हैंडलर के लिए है ।

एक चीज जो इस मॉड्यूल को अलग करती है: यहां कोई start_link या प्रारंभ विधि नहीं है । इवेंट हैंडलर को जोड़ने के कारण ऐसा हुआ, हम eb_event_manager का उपयोग करते हैं : add_handler (मॉड्यूल) विधि, जो वास्तव में, हमारे लिए एक प्रक्रिया शुरू करती है और शुरू करती है!

init([]) ->
{ok, 500}.


Gen_event हैंडलर के लिए आरंभीकरण विधि अन्य सभी Erlang / OTP व्यवहार मॉड्यूल के समान है जिसमें यह {ok, State} देता है , जहां राज्य प्रक्रिया के लिए डेटा की स्थिति का प्रतिनिधित्व करता है। और इस मामले में, हम 500 नंबर लौटाते हैं, जिसका उपयोग हम खाते से निकासी की सूचनाओं के लिए चेतावनी सीमा को इंगित करने के लिए करेंगे।

कैश विदड्रॉल नोटिफिकेशन प्रोसेसिंग

इस ईवेंट हैंडलर का एकमात्र उद्देश्य निकासी अधिसूचना को स्वीकार करना और कुछ करना है अगर निकासी राशि एक निश्चित सीमा से अधिक है। घटना को अतुल्यकालिक संदेश gen_event का उपयोग करके भेजा जाता है : सूचित करें / 2 । हैंडलर्स को एसिंक्रोनस नोटिफिकेशन को handle_event विधि द्वारा परोसा जाता है:

handle_event({withdraw, Name, Amount, NewBalance}, State) when Amount >= State ->
io:format("WITHDRAWAL NOTIFICATION: ~p withdrew ~p leaving ~p left.~n", [Name, Amount, NewBalance]),
{ok, State};
handle_event(_Event, State) ->
{ok, State}.


संदेश को संसाधित करना सरल है। हमने एक घटना को प्राप्त करने के लिए एक वापसी संदेश और सुरक्षा के लिए जाँच करने के लिए एक टेम्पलेट जोड़ा है, केवल तभी जब थ्रेशोल्ड मान की वापसी की मात्रा पार हो जाती है।

जब निकासी राशि सीमा मूल्य से अधिक हो जाती है, तो हम इसे टर्मिनल पर आउटपुट करते हैं।

तैयार eb_withdrawal_handler.erl मॉड्यूल को यहां लिया जा सकता है ।

ऑपरेशन के दौरान थ्रेसहोल्ड परिवर्तन

ErlyBank ने यह भी नोट किया कि वे काम के दौरान नकदी निकासी की अधिसूचना के लिए सीमा को बदलने में सक्षम होना चाहते हैं। ऐसा करने के लिए, हम वास्तविक हैंडलर के लिए एक एपीआई विधि जोड़ेंगे। यहाँ यह है:

%%--------------------------------------------------------------------
%% Function: change_threshold(Amount) -> {ok, Old, NewThreshold}
%% | {error, Reason}
%% Description: Changes the withdrawal amount threshold during runtime
%%--------------------------------------------------------------------
change_threshold(Amount) ->
gen_event:call(eb_event_manager, ?MODULE, {change_threshold, Amount}).


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

हम इस अनुरोध को handle_call / 2 फीडबैक विधि में संसाधित करते हैं:

handle_call({change_threshold, Amount}, State) ->
io:format("NOTICE: Changing withdrawal threshold from ~p to ~p~n", [State, Amount]),
{ok, {ok, State, Amount}, Amount};
handle_call(_Request, State) ->
Reply = ok,
{ok, Reply, State}.


सबसे पहले, हम टर्मिनल पर एक संदेश प्रदर्शित करेंगे कि थ्रेशोल्ड बदल रहा है, फिर हम संदेश के साथ उत्तर देंगे {ok, OldThreshold, NewThreshold} और नए थ्रेशोल्ड मान को डेटा की स्थिति के रूप में सेट करें। अगली वापसी की सूचना मिलने पर, हैंडलर नए चेतावनी मूल्य का उपयोग करेगा! :)

पूर्ण eb_withdrawal_handler मॉड्यूल को यहाँ देखा जा सकता है ।

निष्कर्ष

Gen_event के बारे में इस लेख में , मैंने एक इवेंट मैनेजर लिखने, घटनाओं को भेजने, एक इवेंट हैंडलर को लागू करने, इन घटनाओं को प्राप्त करने और हैंडलर को कॉल करने के बारे में बात की। केवल एक चीज जो मैंने नहीं बताई थी वह gen_event का हिस्सा है, जो इवेंट हैंडलर को डिस्कनेक्ट करने या खुद को दूसरे हैंडलर से बदलने की अनुमति देता है। इसका कारण यह है कि वास्तविक वातावरण में इस तंत्र के साथ काम करने का मेरा अपना व्यापक अनुभव नहीं है। अभी तक मुझे इन अवसरों के लिए आवेदन नहीं मिला है। लेकिन अगर आप उनके बारे में जानना चाहते हैं - प्रलेखन देखें ।

और यह Erlang / OTP परिचय चक्र के तीसरे भाग का समापन करता है। अनुच्छेद चार कुछ दिनों में प्रकाशन के लिए निर्धारित है और पर्यवेक्षकों के बारे में बात करेगा।

---

यूपीडी
कुट्टू हब्रायुज़र की उपस्थिति के लिए धन्यवाद, एक गंभीर चूक की खोज की गई थी, जो मूल पाठ में बनाई गई थी और फिर अनुवाद के लिए चली गई। कृपया ध्यान दें: लेख कहीं भी इंगित नहीं करता है जहां eb_event_manager को कॉल : add_handler (मॉड्यूल) हमारे हैंडलर के लिए बनाया जाना चाहिए। कॉल बाहर नहीं किया जाता है, और इसलिए, हमारे हैंडलर को काम में शामिल नहीं किया गया है। इस स्तर पर हैंडलर को जोड़ने के लिए तार्किक स्थान eb_serverl.erl में init (Args) होगा। आवश्यक परिवर्तन करने के बाद इस पद्धति को देखना चाहिए:

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


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

इसके अलावा, eb_withdrawal_handler हैंडलर के पूर्ण संस्करण का लिंक , जिसे मैं गलती से उद्धृत करना भूल गया था, अनुवाद में जोड़ा गया है।

---

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

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

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