मैसेजिंग -> PubSub OTP के अंदर

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

लेखकों के अनुसार ओटीपी की मुख्य विशिष्ट विशेषता, दोष सहिष्णुता है। मल्टीथ्रेडिंग नहीं, अभिनेता मॉडल नहीं, पैटर्न मिलान की समृद्ध विशेषताएं नहीं, पारदर्शी क्लस्टरिंग भी नहीं और हॉट कोड अपग्रेड नहीं। दोष सहिष्णुता।

एरलैंग की वर्चुअल मशीन सतही रूप से डिज़ाइन की गई है: अलग-अलग मेमोरी के साथ "प्रोसेस" (सिस्टम प्रोसेस नहीं, एरलांग प्रोसेस) का एक गुच्छा है जो संदेशों का आदान-प्रदान कर सकता है। वह सब है। यहाँ जो आर्मस्ट्रांग ने इस बारे में कहा है:

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

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

हां, यह एक नियमित PubSub है, लेकिन OTP के बॉक्स में से इसे लागू नहीं किया गया है। खैर, इससे कोई फर्क नहीं पड़ता, हमारे पास अपने घुटनों पर लाने के लिए एक घंटे में सभी ईंटें हैं। चलिए शुरू करते हैं।

कार्यान्वयन के विकल्प

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

Phoenix.PubSub हमारे लिए, Phoenix.PubSub का एक वितरित कार्यान्वयन है, जो दो तैयार किए गए कार्यान्वयनों के साथ आता है: Phoenix.PubSub.PG2 और Phoenix.PubSub.Redis । ठीक है, Redis स्पष्ट रूप से हमारी श्रृंखला में एक अतिरिक्त कड़ी है, लेकिन PG2 प्रक्रियाओं के pg2 समूहों के शीर्ष पर काम कर रहा PG2 है। इसके अलावा, हालांकि, एक बॉयलरप्लेट के बिना नहीं होगा।

तो, हमारे पास हमारे आवेदन में सुविधाजनक पबसब सदस्यताएँ स्थापित करने के लिए सब कुछ है। क्या पाठ संपादक खोलने का समय है? "वास्तव में नहीं।" मुझे प्रोजेक्ट से प्रोजेक्ट में डुप्लिकेट कोड पसंद नहीं है, और जो कुछ भी मैं लाइब्रेरी में अलग कर सकता हूं, उसका पुन: उपयोग के लिए अलग किया जाता है।

envio

इस प्रकार Envío पैकेज का जन्म हुआ। चूंकि बकवास, जैसा कि आप जानते हैं, एक पैसे के लायक नहीं है, हम उपयोग के उदाहरणों के साथ शुरू करेंगे।

स्थानीय न्यूज़लैटर → Registry

 defmodule MyApp.Sub do use Envio.Subscriber, channels: [{MyApp.Pub, :main}] def handle_envio(message, state) do # optionally call the default implementation {:noreply, state} = super(message, state) # handle it! IO.inspect({message, state}, label: "Received") # respond with `{:noreply, state}` as by contract {:noreply, state} end end 

यह, सामान्य तौर पर, सभी है। यह MyApp.Sub को हमारे पर्यवेक्षक वृक्ष में MyApp.Sub लिए बना हुआ है, और यह प्रक्रिया MyApp.Pub से कार्यों का उपयोग करके भेजे गए सभी संदेशों को प्राप्त करना शुरू कर MyApp.Pub , जो कोड के साथ अतिभारित नहीं है।

 defmodule MyApp.Pub do use Envio.Publisher, channel: :main def publish(channel, what), do: broadcast(channel, what) def publish(what), do: broadcast(what) # send to :main end 

वितरित न्यूज़लैटर → PG2

कई नोड्स वाले वितरित सिस्टम के लिए, यह विधि काम नहीं करेगी। हमें अन्य नोड्स से संदेशों की सदस्यता लेने में सक्षम होने की आवश्यकता है, और Registry यहां सहायक नहीं है। लेकिन PG2 है जो समान behaviour लागू करता behaviour ।

 defmodule Pg2Sucker do use Envio.Subscriber, channels: ["main"], manager: :phoenix_pub_sub def handle_envio(message, state) do {:noreply, state} = super(message, state) IO.inspect({message, state}, label: "Received") {:noreply, state} end end 

ऊपर दिए गए स्टैंडअलोन कोड से एकमात्र अंतर manager: :phoenix_pub_sub पैरामीटर है, जिसे हम स्थानीय Registry बजाय :pg2 पर आधारित मॉड्यूल का निर्माण करने के use Envio.Subscriber (और use Envio.Publisher करने के लिए) पास करते use Envio.Subscriber । अब इस Publisher का उपयोग करके भेजे गए संदेश क्लस्टर के सभी नोड्स पर उपलब्ध होंगे।

आवेदन

Envío तथाकथित बैकेंड का समर्थन करता है। Envio.Slack साथ आता है, जो आपको Envio.Slack को संदेश भेजने को सरल बनाने की अनुमति देता है। आवेदन के लिए आवश्यक सभी - config/prod.exs में कॉन्फ़िगर किए गए चैनल को एक संदेश भेजें - Envío काम करेंगे। यहाँ एक उदाहरण विन्यास है:

 config :envio, :backends, %{ Envio.Slack => %{ {MyApp.Pub, :slack} => [ hook_url: {:system, "SLACK_ENVIO_HOOK_URL"} ] } } 

अब MyApp.Pub.publish(:slack, %{foo: :bar}) कॉल करके भेजे गए सभी संदेश MyApp.Pub.publish(:slack, %{foo: :bar}) में संबंधित चैनल पर वितरित किए जाएंगे, खूबसूरती से स्वरूपित। स्लैक को संदेश भेजने से रोकने के लिए, बस Envio.Slack प्रक्रिया को Envio.Slack । अधिक उदाहरण (उदाहरण के लिए, IO में एक लॉग) परीक्षणों में पाया जा सकता है।

मैं क्यों क्रूस पर चढ़ा रहा हूँ, इसे स्वयं आजमाएँ।

 def deps do [ {:envio, "~> 0.8"} ] end 

अच्छा संचार!