🕶️ 🚏 🤜🏼 Django चैनल - आधुनिक वेब का जवाब 🛕 🤳 🧑🏿‍🤝‍🧑🏿

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

सबसे पहले, ज़ेन ज़ेन का कहना है कि कोई भी समाधान एकमात्र होना चाहिए। इसलिए, पायथन में कम से कम तीन प्रत्येक हैं । पहले से ही बहुत सारे नेटवर्क अतुल्यकालिक ढांचे हैं:

मुड़;
eventlet;
Gevent;
तूफान;
Asyncio।

ऐसा लगता है, क्यों एक और पुस्तकालय लिखना चाहिए और क्या यह बिल्कुल आवश्यक है।

स्पीकर के बारे में: अर्टिओम मालिशेव एक स्वतंत्र पायथन डेवलपर है। वह वितरित प्रणालियों के विकास में लगे हुए हैं, पायथन पर सम्मेलनों में बोलते हैं। Artyom को PROOFIT404 उपनाम Github पर और सोशल नेटवर्क पर पाया जा सकता है।

Django परिभाषा द्वारा तुल्यकालिक है । अगर हम ORM के बारे में बात कर रहे हैं, तो जब हम लिखते हैं, तब एट्रिब्यूट एक्सेस के दौरान डेटाबेस को सिंक्रोनाइज़ करते हैं, उदाहरण के लिए, post.author.username, कुछ भी नहीं।

इसके अलावा, Django एक WSGI फ्रेमवर्क है।

WSGI

WSGI वेब सर्वर के साथ काम करने के लिए एक तुल्यकालिक इंटरफ़ेस है।

def app (environ, callback) : status, headers = '200 OK', [] callback (status, headers) return ['Hello world!\n']

इसकी मुख्य विशेषता यह है कि हमारे पास एक फ़ंक्शन है जो एक तर्क लेता है और तुरंत एक मूल्य देता है। यह सभी वेब सर्वर हमसे उम्मीद कर सकते हैं। कोई एसिंक्रोनस और गंध नहीं करता है ।

यह बहुत समय पहले किया गया था, 2003 में वापस, जब वेब सरल था, उपयोगकर्ताओं ने इंटरनेट पर सभी प्रकार की खबरें पढ़ीं, और अतिथि पुस्तकों में चले गए। यह केवल अनुरोध को स्वीकार करने और इसे संसाधित करने के लिए पर्याप्त था। एक उत्तर दें और यह भूल जाएं कि यह उपयोगकर्ता बिल्कुल था।

लेकिन, एक सेकंड के लिए, अब वर्ष 2003 नहीं है, इसलिए उपयोगकर्ता हमसे बहुत अधिक चाहते हैं।

वे रिच वेब एप्लिकेशन, लाइव सामग्री चाहते हैं, वे चाहते हैं कि एप्लिकेशन डेस्कटॉप पर, लैपटॉप पर, अन्य शीर्ष पर, घड़ी पर शानदार काम करे। सबसे महत्वपूर्ण बात, उपयोगकर्ता F5 को दबाना नहीं चाहते हैं , क्योंकि, उदाहरण के लिए, गोलियों में ऐसा कोई बटन नहीं है।

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

लेकिन, बैकएंड प्रोग्रामर्स के लिए, सब कुछ बहुत बदल गया है । वेब सॉकेट्स, HTTP2 और जैसे आर्किटेक्चर के संदर्भ में एक बहुत बड़ा दर्द है, क्योंकि वे अपने राज्यों के साथ लंबे समय तक रहने वाले कनेक्शन हैं जिन्हें किसी भी तरह संभालने की आवश्यकता है।

यह समस्या है कि Django चैनल के लिए Django हल करने की कोशिश कर रहा है। यह लाइब्रेरी आपको कनेक्शन संभालने की क्षमता प्रदान करने के लिए डिज़ाइन की गई है, Django कोर को छोड़कर हम पूरी तरह से अपरिवर्तित हैं।

उन्हें एंड्रयू गॉडविन द्वारा एक अद्भुत व्यक्ति बनाया गया था, जो एक भयानक अंग्रेजी उच्चारण के मालिक थे जो बहुत जल्दी बोलता है। आपको इसे ऐसी चीजों से जानना चाहिए जो लंबे समय से भूले हुए Django साउथ और Django माइग्रेशन के रूप में हैं, जो संस्करण 1.7 से हमारे पास आया था। जब से उन्होंने Django के लिए माइग्रेशन तय किया, तब से उन्होंने वेब सॉकेट और HTTP2 की मरम्मत शुरू कर दी।

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

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

इसका अर्थ है कई कार्यान्वयन, और उत्पादन में यह एक अतुल्यकालिक सर्वर के रूप में ट्विस्टेड का उपयोग करने का प्रस्ताव है जो Django और Redis के लिए दृश्यपटल को लागू करता है, जो तुल्यकालिक Django और अतुल्यकालिक मुड़ के बीच एक ही संचार चैनल होगा।

अच्छी खबर: Django चैनल का उपयोग करने के लिए, आपको या तो ट्विस्टेड या रेडिस को जानने की आवश्यकता नहीं है - ये सभी कार्यान्वयन विवरण हैं। आपके DevOps को यह पता चल जाएगा, या आप मिलेंगे जब आप सुबह तीन बजे एक गिरते उत्पादन की मरम्मत करेंगे।

ASGI

एब्स्ट्रेक्शन एक प्रोटोकॉल है जिसे एएसजीआई कहा जाता है। यह मानक इंटरफ़ेस है जो किसी भी नेटवर्क इंटरफ़ेस, सर्वर के बीच स्थित है, चाहे वह एक सिंक्रोनस या एसिंक्रोनस प्रोटोकॉल और आपका एप्लिकेशन हो। इसकी मुख्य अवधारणा चैनल है।

चैनल

एक चैनल उन संदेशों की पहली-पहली-पहली कतार है, जिनमें जीवनकाल है। ये संदेश शून्य या एक बार दिए जा सकते हैं, और केवल एक उपभोक्ता द्वारा प्राप्त किए जा सकते हैं।

उपभोक्ताओं

कंज्यूमर में, आप सिर्फ अपना कोड लिख रहे हैं।

 def ws_message (message) : message.reply_channel.send ( { 'text': message.content ['text'], } )

एक फ़ंक्शन जो किसी संदेश को स्वीकार करता है, वह कई प्रतिक्रियाएं भेज सकता है, या यह एक प्रतिक्रिया नहीं भेज सकता है। देखने के लिए बहुत समान है, केवल अंतर यह है कि कोई रिटर्न फ़ंक्शन नहीं है, इसलिए हम इस बारे में बात कर सकते हैं कि हम फ़ंक्शन से कितने उत्तर देते हैं।

हम इस फ़ंक्शन को रूटिंग में जोड़ते हैं, उदाहरण के लिए, वेब सॉकेट पर एक संदेश प्राप्त करने के लिए इसे लटकाएं।

 from channels.routing import route from myapp.consumers import ws_message channel_routing = [ route ('websocket.receive' ws_message), }

हम इसे Django सेटिंग्स में लिखते हैं, जैसे डेटाबेस निर्धारित किया जाएगा।

 CHANNEL_LAYERS = { 'default': { 'BACKEND': 'asgiref.inmemory', 'ROUTING': 'myproject.routing', }, }

एक परियोजना में कई चैनल परतें हो सकती हैं, जैसे कई डेटाबेस हो सकते हैं। यह बात db राऊटर से काफी मिलती जुलती है अगर कोई इसका इस्तेमाल करता है।

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

 import os from channels.asgi import get_channel_layer os.environ.setdefault( 'DJANGO_SETTINGS_MODULE', 'myproject.settings', ) channel_layer = get_channel_layer()

उसके बाद, कोड को तैनात करें: gunicorn चलाएं, मानक रूप से एक HTTP अनुरोध भेजें, तुल्यकालिक रूप से, दृश्य के साथ, जैसा कि आप उपयोग कर रहे हैं। हम एसिंक्रोनस सर्वर शुरू करते हैं, जो हमारे सिंक्रोनस Django के सामने सबसे आगे होगा, और जो कार्यकर्ता संदेशों को संसाधित करेंगे।

 $ gunicorn myproject.wsgi $ daphne myproject.asgi:channel_layer $ django-admin runworker

Reply चैनल

जैसा कि हमने देखा, संदेश में उत्तर चैनल जैसा एक अवधारणा है। इसकी आवश्यकता क्यों है?

चैनल यूनिडायरेक्शनल, क्रमशः WebSocket प्राप्त, WebSocket कनेक्ट, WebSocket डिस्कनेक्ट - यह आने वाले संदेशों के लिए सिस्टम का एक सामान्य चैनल है। एक उत्तर चैनल एक चैनल है जो उपयोगकर्ता के कनेक्शन से कड़ाई से जुड़ा हुआ है। तदनुसार, संदेश में एक इनपुट और आउटपुट चैनल है। यह जोड़ी आपको यह पहचानने की अनुमति देती है कि यह संदेश किसके पास से आया है।

समूह

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

 from channels import Group def ws_connect (message): Group ('chat').add (message.reply_channel) def ws_disconnect (message): Group ('chat').discard(message.reply_channel) def ws_message (message): Group ('chat'). Send ({ 'text': message.content ['text'], })

समूहों को उसी तरह से रूट करने के लिए भी जोड़ा जाता है।

 from channels.routing import route from myapp.consumers import * channel_routing = [ route ('websocket.connect' , ws_connect), route ('websocket.disconnect' , ws_disconnect), route ('websocket.receive' , ws_message), ]

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

सामान्य उपभोक्ता

क्या मैं Django के लिए प्यार करता हूँ घोषणात्मक है। इसी तरह, घोषणात्मक उपभोक्ता हैं।

बेस कंज्यूमर एक बेसिक है, यह केवल उस चैनल को मैप कर सकता है जिसे आपने किसी तरीके से परिभाषित किया है और इसे कॉल करें।

 from channels.generic import BaseConsumer class MyComsumer (BaseConsumer) : method_mapping = { 'channel.name.here': 'method_name', } def method_name (self, message, **kwargs) : pass

जानबूझकर संवर्धित व्यवहार के साथ पूर्वनिर्धारित उपभोक्ताओं की एक बड़ी संख्या है, जैसे कि वेबसोकेट उपभोक्ता, जो पूर्व-निर्धारित करता है कि यह WebSocket कनेक्ट, WebSocket प्राप्त, WebSocket डिस्कनेक्ट को संभाल लेगा। आप तुरंत संकेत दे सकते हैं कि कौन से समूह में उत्तर चैनल जोड़ना है, और जैसे ही आप self.send का उपयोग करते हैं, वह समझ जाएगा कि यह समूह में या किसी एक उपयोगकर्ता को भेजना है या नहीं।

 from channels.generic import WebsocketConsumer class MyConsumer (WebsocketConsumer) : def connection_groups (self) : return ['chat'] def connect (self, message) : pass def receive (self, text=None, bytes=None) : self.send (text=text, bytes=bytes)

JSON के साथ एक WebSocket उपभोक्ता विकल्प भी है, यानी टेक्स्ट नहीं, बाइट्स नहीं, लेकिन पहले से पार्स किया गया JSON प्राप्त करने के लिए आएगा, जो सुविधाजनक है।

रूटिंग में, इसे उसी तरह से जोड़ा जाता है जैसे मार्ग_क्लास के माध्यम से। Myapp को path_class में लिया जाता है, जो उपभोक्ता से निर्धारित होता है, सभी चैनल वहां से लिए जाते हैं और myapp में निर्दिष्ट सभी चैनल रूट किए जाते हैं। इस तरह कम लिखिए।

रूटिंग

आइए रूटिंग के बारे में विस्तार से बात करते हैं और यह हमें क्या प्रदान करता है।

सबसे पहले, ये फ़िल्टर हैं।

 // app.js S = new WebSocket ('ws://localhost:8000/chat/') # routing.py route('websocket.connect', ws_connect, path=r'^/chat/$')

यह वह रास्ता हो सकता है जो वेब सॉकेट कनेक्शन URI, या http अनुरोध विधि से हमारे पास आया था। यह चैनल से कोई भी संदेश क्षेत्र हो सकता है, उदाहरण के लिए, ई-मेल के लिए: टेक्स्ट, बॉडी, कार्बन कॉपी, जो भी हो। मार्ग के लिए कीवर्ड तर्क की संख्या मनमानी है।

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

 from channels import route, include blog_routes = [ route ( 'websocket.connect', blog, path = r'^/stream/') , ] routing = [ include (blog_routes, path= r'^/blog' ), ]

बहुसंकेतन

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

इसलिए, एक वेब सॉकेट पर कई हैंडलर को कॉल करना संभव है। हम ऐसे WebsocketDemultiplexer को परिभाषित करते हैं जो एकल वेब सॉकेट के भीतर स्ट्रीम की अवधारणा पर काम करता है। इस स्ट्रीम के माध्यम से, यह आपके संदेश को दूसरे चैनल पर रीडायरेक्ट करेगा।

 from channels import WebsocketDemultiplexer class Demultiplexer (WebsocketDemultiplexer) : mapping = { 'intval': 'binding.intval', }

रूटिंग में, मल्टीप्लेक्सर को उसी तरह से जोड़ा जाता है जैसे किसी अन्य घोषणात्मक उपभोक्ता मार्ग_क्लास में।

 from channels import route_class, route from .consumers import Demultiplexer, ws_message channel_routing = [ route_class (Demultiplexer, path='^/binding/') , route ('binding.intval', ws_message ) , ]

संदेश में स्ट्रीम तर्क जोड़ा जाता है ताकि मल्टीप्लेक्स यह पता लगा सके कि दिए गए संदेश को कहां रखा जाए। पेलोड तर्क में वह सब कुछ होता है जो मल्टीप्लेक्स प्रक्रियाओं के बाद चैनल में जाता है।

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

 { "stream" : "intval", "payload" : { … } }

सत्र

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

 from channels.sessions import channel_session @channel_session def ws_connect(message) : room=message.content ['path'] message.channel_session ['room'] = room Croup ('chat-%s' % room).add ( message.reply_channel )

कनेक्शन के दौरान, आप एक http सत्र प्राप्त कर सकते हैं और इसे अपने उपभोक्ता में उपयोग कर सकते हैं। बातचीत प्रक्रिया के भाग के रूप में, वेब सॉकेट कनेक्शन स्थापित करते हुए, कुकीज़ उपयोगकर्ता को भेजी जाती हैं। तदनुसार, इसलिए, आप एक उपयोगकर्ता सत्र प्राप्त कर सकते हैं, उस उपयोगकर्ता वस्तु को प्राप्त कर सकते हैं जिसे आपने पहले Django में उपयोग किया था, जैसे कि आप दृश्य के साथ काम कर रहे थे।

 from channels.sessions import http_session_user @http_session_user def ws_connect(message) : message.http_session ['room'] = room if message.user.username : …

संदेश आदेश

चैनल एक बहुत महत्वपूर्ण समस्या को हल कर सकते हैं। यदि हम एक वेब सॉकेट के लिए एक कनेक्शन स्थापित करते हैं और तुरंत भेजते हैं, तो यह इस तथ्य की ओर जाता है कि दो घटनाएँ - WebSocket कनेक्ट और WebSocket प्राप्त - समय के बहुत करीब हैं। यह बहुत संभावना है कि इन वेब सॉकेट के लिए उपभोक्ता समानांतर में चलेगा। इसका डेब्यू करना काफी मजेदार होगा।

Django चैनल आपको दो प्रकार के लॉक दर्ज करने की अनुमति देता है:

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

 from channels.generic import WebsocketConsumer class MyConsumer(WebsocketConsumer) : http_user = True slight_ordering = True strict_ordering = False def connection_groups (self, **kwargs) : return ['chat']

इसे लिखने के लिए, वही डेकोरेटर हैं जो हमने पहले http सेशन, चैनल सेशन में देखे थे। घोषणात्मक उपभोक्ता में, आप केवल विशेषताएँ लिख सकते हैं, जैसे ही आप उन्हें लिखते हैं, यह स्वचालित रूप से इस उपभोक्ता के सभी तरीकों पर लागू होगा।

डेटा बाइंडिंग

एक समय में, Meteor डेटा बाइंडिंग के लिए प्रसिद्ध हो गया।

हम दो ब्राउज़र खोलते हैं, एक ही पेज पर जाते हैं, और उनमें से एक में हम स्क्रॉल बार पर क्लिक करते हैं। उसी समय, दूसरे ब्राउज़र में, इस पृष्ठ पर, स्क्रॉल बार अपना मान बदलता है। यह मस्त है।

 class IntegerValueBinding (WebsocketBinding) : model = IntegerValue stream = intval' fields= ['name', 'value'] def group_names (self, instance, action ) : return ['intval-updates'] def has_permission (self, user, action, pk) : return True

Django अब सिर्फ एक ही है।

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

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

लाल परत

आइए थोड़ा और बात करें कि उत्पादन के लिए सबसे लोकप्रिय चैनल लेयर की व्यवस्था कैसे की जाती है - रेडिस।

यह अच्छी तरह से व्यवस्थित है:

श्रमिकों के स्तर पर समकालिक कनेक्शन के साथ काम करता है;
ट्विस्टेड के लिए बहुत अनुकूल, धीमा नहीं पड़ता है, जहां यह विशेष रूप से आवश्यक है, जो आपके फ्रंट-एंड सर्वर पर है;
MSGPACK का उपयोग Redis के अंदर संदेशों को क्रमबद्ध करने के लिए किया जाता है, जो प्रत्येक संदेश पर पदचिह्न को कम करता है;
आप कई Redis उदाहरणों को लोड वितरित कर सकते हैं, यह सुसंगत हैश एल्गोरिथ्म का उपयोग करके स्वचालित रूप से फेरबदल किया जाएगा। इस प्रकार, विफलता का एक बिंदु गायब हो जाता है।

एक चैनल रेडिस से सिर्फ एक आईडी सूची है। आईडी द्वारा एक विशेष संदेश का मूल्य है। ऐसा इसलिए किया जाता है ताकि आप प्रत्येक संदेश और चैनल के जीवन को अलग-अलग नियंत्रित कर सकें। सिद्धांत रूप में, यह तर्कसंगत है।

 >> SET "b6dc0dfce" " \x81\xa4text\xachello" >> RPUSH "websocket.send!sGOpfny" "b6dc0dfce" >> EXPIRE "b6dc0dfce" "60" >> EXPIRE "websocket.send!sGOpfny" "61"

समूह सॉर्ट किए गए सेट द्वारा कार्यान्वित किए जाते हैं। समूहों में वितरण लुआ लिपि के अंदर किया जाता है - यह बहुत तेज़ है।

 >> type group:chat zset >> ZRANGE group:chat 0 1 WITHSCORES 1) "websocket.send!sGOpfny" 2) "1476199781.8159261"

समस्याएं

आइए देखें कि इस दृष्टिकोण में क्या समस्याएं हैं।

कॉलबैक नरक

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

अजवाइन

इंटरनेट पर, वे लिखते हैं कि Django चैनल सेलेरी के लिए एक प्रतिस्थापन है।

मेरे पास आपके लिए बुरी खबर है - नहीं, यह नहीं है।

चैनलों में:

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

मैं न्यूनतम प्रयास के साथ, न्यूनतम लागत के साथ, चैनल और अजवाइन का एक साथ उपयोग करने के लिए भविष्य में आधिकारिक समर्थन के रूप में देखता हूं। लेकिन Django चैनल सेलेरी के लिए एक प्रतिस्थापन नहीं है।

आधुनिक वेब के लिए Django

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

मॉस्को पायथन कॉन्फिडेंस ++

पायथन डेवलपर्स के लिए एक पेशेवर सम्मेलन एक नए स्तर पर चला जाता है - 22 और 23 अक्टूबर, 2018 को हम रूस में 600 सर्वश्रेष्ठ पायथन प्रोग्रामर इकट्ठा करेंगे, सबसे दिलचस्प रिपोर्ट पेश करेंगे और निश्चित रूप से, ओटिको की टीम के सहयोग से मॉस्को पायथन समुदाय की सर्वश्रेष्ठ परंपराओं में नेटवर्किंग के लिए एक वातावरण तैयार करेंगे।

हम एक रिपोर्ट बनाने के लिए विशेषज्ञों को आमंत्रित करते हैं। कार्यक्रम समिति पहले से ही काम कर रही है और 7 सितंबर तक आवेदन स्वीकार करती है।

प्रतिभागियों के लिए, एक ऑनलाइन मंथन कार्यक्रम आयोजित किया जा रहा है। आप इस दस्तावेज़ या बोलने वालों के लिए ऐसे लापता विषय जोड़ सकते हैं जिनके भाषण आपके हित में हों। दस्तावेज़ को अद्यतन किया जाएगा, वास्तव में, हर समय आप कार्यक्रम के गठन का पालन कर सकते हैं।

Django चैनल - आधुनिक वेब का जवाब