SynapseGrid के साथ वास्तविक समय घटना प्रसंस्करण

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

पूरे खेत को एक आवेदन उदाहरण के ढांचे के भीतर काम करना था, लेकिन एक ही समय में ग्राहक कोड (जैसे बीन्स) के लिए लगभग समान स्वतंत्र बहुत से नेस्टेड होना चाहिए।

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

प्रतिरूपकता

चूंकि हमने "बनाया - भूल" श्रृंखला से एक अलग लागू कार्य को हल नहीं किया, लेकिन एक टूलकिट लागू किया जिसने हमें समस्याओं के एक परिवार को हल करने की अनुमति दी, विकास सिद्धांतों में से एक मॉड्यूलरिटी का सिद्धांत था। यही है, हमने अलग-अलग पुन: प्रयोज्य घटकों का निर्माण किया, जिन्हें परिवार से किसी भी समस्या को हल करने के लिए सिस्टम बनाने के लिए लगभग मनमाने तरीके से जोड़ा जाना था।

ऑडियो स्ट्रीमिंग

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

तब हमने पाया कि यदि ऑडियो स्ट्रीम को फ्रेम (10-40 एमएस की एक निश्चित लंबाई के टुकड़े) में विभाजित किया जाता है, तो मॉड्यूल को कनेक्ट करना बहुत आसान है। ऑडियो के टुकड़ों को एक नियमित कतार में रखा जा सकता है और कतार को अवरुद्ध किए बिना जाँच की जा सकती है।

कई कार्यों में प्राथमिक ऑडियो प्रसंस्करण लगभग रेखीय निकला। यानी मॉड्यूल को एक श्रृंखला में व्यवस्थित किया गया था जिसमें पिछले मॉड्यूल का आउटपुट बाद के मॉड्यूल के इनपुट से जुड़ा था। इस संरचना को आमतौर पर पाइपलाइन कहा जाता है।

डेटा ट्रांसफर को व्यवस्थित करने के तीन तरीके हैं:

1. खींच

def getData = process(previousModule.getData) 

2. धक्का

  def pushData(d:data) { val res = process(d) nextModule.pushData(res) } 

3. कार्यात्मक एकत्रीकरण

  def f(d:data) = { val r1 = module1.f(d) val r2 = module2.f(r1) r2 } 

खींचने के मामले में, डेटा पिछले घटक से "खींचा" जाता है, और पिछले घटकों की श्रृंखला अप्राप्य है और कुछ बफर में डेटा की कमी के कारण अवरुद्ध हो सकती है। जब कोई अपवाद होता है, तो संपूर्ण स्टैक ढह जाता है, जिससे काम करना जारी रखना असंभव हो जाता है।

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

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

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

 trait MapModule[TIn, TOut] { def f(data:TIn):TOut } 

दूसरे प्रकार ( flatMap ) के मॉड्यूल में आंतरिक बफरिंग मॉड्यूल के लिए विशिष्ट थी और इसमें आउटपुट संग्रह था जिसमें 0..n तत्व थे:

 trait FlatMapModule[TIn, TOut] { def f(data:TIn):Collection[TOut] } 

पाइप लाइन के माध्यम से डेटा को "पंप" करने के लिए, दो रणनीतियों का उपयोग किया जा सकता है - गहराई पहले या चौड़ाई पहले।

 def widthFirst(d:Data) = { val r1:Collection[...] = module1.f(d) val r2 = for(d1 <- r1; d2 <- module2.f(d1)) yield d2 val r3 = for(d2 <- r2; d3 <- module3.f(d2)) yield d3 r3 } def depthFirst(d:Data) = { for(d1 <- module1.f(d); d2 <- module2.f(r1); d3 <- module3.f(d2) ) yield d3 } 

पहले गहराई पर, प्रत्येक तत्व को श्रृंखला के अंत तक ट्रेस किया गया था, और फिर अगले इनपुट तत्व को संसाधित किया गया था। पहले चौड़ाई के साथ, सभी तत्वों ने पहले चरण को पारित किया, फिर सभी प्राप्त तत्वों ने दूसरे चरण को पारित किया, आदि।

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

सदस्यता मॉडल

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

हम जल्दी से घटनाओं के लिए एक सदस्यता योजना के साथ आए। एक ईवेंट [T] ऑब्जेक्ट बनाया गया था जिसमें एक तरफ डेटा डालना और दूसरे पर नए डेटा की सदस्यता लेना संभव था। इसने मॉड्यूल को डिकॉय करने की अनुमति दी। घटना को अतुल्यकालिक और धागा सुरक्षित बनाया गया था। बनाई गई योजना RxJava लाइब्रेरी से बहुत मिलती- जुलती है (वहां इस घटना को ऑब्जर्वेबल [T] कहा जाता है)।

सदस्यता मॉडल बहुत अच्छा था और कई स्वतंत्र थ्रेड्स में काम को व्यवस्थित करना काफी आसान बना दिया। हमारी योजना में ऑब्जर्वेबल से एक अंतर यह था कि ईवेंट के इनपुट पर, डेटा कई स्रोतों से आ सकता है।


अंजीर। 1 कई-से-कई, सीधे


Fig.2 "स्टार" योजना के अनुसार कई-से-कई


जैसे-जैसे परियोजना विकसित हुई, घटनाओं की संख्या में वृद्धि हुई और इस योजना की सीमाएँ सामने आईं।

1. यह ज्ञात नहीं है कि कोई भी इस घटना को उत्पन्न कर रहा है या नहीं।
2. यह ज्ञात नहीं है कि किसी ने घटना के लिए सदस्यता ली है या नहीं।
3. डेटा स्ट्रीम अप्रत्यक्ष रूप से प्रवाहित होती हैं - एक घटना, एक हैंडलर, किसी अन्य घटना की छिपी हुई आंतरिक पीढ़ी (?), दूसरी हैंडलर इत्यादि।
4. यदि सदस्यता समकालिक है, अर्थात चूंकि हैंडलर को कॉलिंग थ्रेड में निष्पादित किया जाता है, इसलिए यह स्पष्ट नहीं है कि अपवाद के साथ क्या करना है।

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

अक्का

इस बिंदु पर, अक्का का उपयोग पहले से ही रीमोट करने के लिए किया गया था , और यह आशाजनक लग रहा था। कम से कम, एक मल्टीकाडिंग को अक्का में स्थानांतरित करने और घटनाओं के साथ कुछ समस्याओं को हल करने की उम्मीद कर सकता है।

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

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

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

कल का नवाब

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

यह प्रणाली तथाकथित "जाली", या निर्देशित ग्राफ (डिग्राफ) का वर्णन करती है। जाली के नोड ईवेंट हैं, और शाखाएं हैंडलर हैं। ग्राफ में निर्मित समानता के कारण, अपस्टार्ट आपको सिस्टम वी की तुलना में बहुत पहले हैंडलर चलाने की अनुमति देता है, जो कि अलग-अलग परतों (रनलेवल 0..6) पर आधारित है। स्वतंत्र हैंडलर चुपचाप समानांतर काम करते हैं।

अपस्टार्ट के विचारों ने संपर्क प्रणाली के आगे विकास को प्रभावित किया।

संपर्क प्रणाली संस्करण 1

जब तक हम एक घटना के साथ एक स्टार की तस्वीर पर विचार करते हैं (ऊपर की आकृति में दिखाया गया है), हम एक बहु-थ्रेडेड सिस्टम के आयोजन के लिए एक अच्छे तंत्र के साथ नहीं आ पाएंगे। लेकिन अगर आप एक निर्देशित ग्राफ बनाते हैं, तो दिलचस्प संभावनाएं पहले से ही खींची जा रही हैं।


अंजीर। 3 घटनाओं और घटना हैंडलर


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

पहले संस्करण में, हमने बस इवेंट [T] को सामान्यीकृत और अनुकूलित किया, लेकिन वितरित ("स्मीयर") संदेश पासिंग तंत्र को बनाए रखा। अपने आप में प्रसंस्करण ग्राफ की उपस्थिति ने सिस्टम के संचालन को समझना और वर्तमान समस्याओं को हल करना संभव बना दिया। लेकिन अनिवार्य बफरिंग और सुरक्षित स्ट्रीम-सुरक्षित के साथ इस तरह के "स्मीयर" मैसेजिंग तंत्र, सिस्टम के अन्य हिस्सों में समान समस्याओं को हल करने के लिए उपयुक्त नहीं था। इसे कुछ समान की आवश्यकता थी, लेकिन अधिक हल्के।

अक्का में हल्के डॉक्टरों के संचालन का तंत्र

यहां, हल्के डॉक्टरों के तंत्र पर एक छोटे से विषयांतर की आवश्यकता होती है, जिसमें सिनैप्सग्रिड वास्तुकला के साथ कई समानताएं हैं।

निम्नलिखित कोड पर विचार करें:

 val helloActorRef = actor(new Act { become { case "hello" ⇒ sender ! "hi" } }) helloActorRef ! "Hello" 

जब हम एक्टर को "हैलो" संदेश भेजते हैं, तो हमारे संदेश के चारों ओर एक आवरण बनाया जाता है:

  Message(helloActorRef, "Hello") 

और यह संदेश पंक्तिबद्ध है। समानांतर में कहीं 16 धागे हैं जो इस बड़ी कतार से संदेश पढ़ते हैं। और एक निश्चित प्रेषणकर्ता भी है जो यह सुनिश्चित करता है कि दो धागे एक ही ट्रैक्टर के साथ एक साथ काम नहीं करते हैं। थ्रेड संदेश को पकड़ लेता है, ईकर पाता है और बस हमारे संदेश ("हेलो") पर इस इक्टर का कार्य करता है।

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

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

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

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

एक और सादृश्य जो दिमाग में आता है वह है विशाल स्पा का उपयोग विशाल विरल सरणियों को संग्रहीत करने के लिए। हम त्रि-आयामी अंतरिक्ष में कई बिंदुओं के लिए कुछ डेटा कैसे बचाते हैं? हमारे त्रि-आयामी अंतरिक्ष का आकार 1000x1000x1000 हो। यदि सरणियों में संग्रहीत किया जाता है, तो 10e9 कोशिकाओं की आवश्यकता होती है। और यदि आप लेबल (x, y, z) का उपयोग करते हैं, तो आपको बहुत कम मेमोरी की आवश्यकता होगी। यहाँ HashMap[(x,y,z), data] बस काम करता है।

सिस्टम संस्करण 2 या SynapseGrid से संपर्क करें

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

इसलिए, जिन घटनाओं की आप सदस्यता ले सकते हैं, उनका प्रतिनिधित्व करने के लिए, हम संपर्क की अवधारणा का परिचय देते हैं,

  val contact1 = Contact[T]("1") 

और इस संपर्क से जुड़े संदेशों का प्रतिनिधित्व करने के लिए, एक संकेत ।

  Signal[T](contact1, data:T) 

जैसा कि आप देख सकते हैं, संपर्क ActorRef के समान है, और संकेत संदेश के समान है। अंतर यह है कि संपर्क के साथ न तो राज्य और न ही व्यवहार जुड़ा हुआ है। यह सिर्फ एक पहचानकर्ता है। यदि हम एक आभासी "कतार" के साथ सादृश्य को याद करते हैं, तो संपर्क इस कतार की पहचान करता है।

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

बाहरी लिंकिंग

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

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

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

जैसा कि ऊपर उल्लेख किया गया है, पूरे सिस्टम का मॉडल एक निर्देशित ग्राफ है। यदि आप बारीकी से देखते हैं, तो आप देख सकते हैं कि यह एक द्विदलीय ग्राफ है। लेकिन अधिकांश मामलों में, प्राथमिक हैंडलर नक्शे या फ्लैटपाइप घटक होते हैं जिनमें एक इनपुट और एक आउटपुट होता है। इसलिए, SynapseGrid के दिल में हम एक सरल ग्राफ डालते हैं, जिनमें से नोड्स संपर्कों के अनुरूप होते हैं, और आर्क डेटा को प्रोसेस करने वाले घटकों से जुड़े होते हैं। यानी ग्राफ ट्रिपल्स (contact1, contact2, हैंडलर) के एक सेट द्वारा दिया गया है:

  Link[TIn, TOut](from:Contact[TIn], to:Contact[TOut],function: TIn=>Collection[TOut]) 

(यहां हम इस तथ्य का लाभ उठाते हैं कि मानचित्र घटक फ्लैटपाइप घटकों का एक विशेष मामला है)।

SynapseGrid का विवरण ब्रेडबोर्ड के लिए एक दिलचस्प रूपक प्रदान करता है जो SynapseGrid के विचार को अच्छी तरह से दिखाता है।

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

बाइडर्स और डीएसएल

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

संपर्क प्रणाली के लिए, हमने DSL SystemBuilder विकसित किया, जिसमें सभी अवसरों के लिए कई तरीके हैं, जिससे आप सिस्टम को चरण दर चरण डिज़ाइन कर सकते हैं।

  val in = input[Int]("in") // input -    ,       val c = contact[Int]("c") (in -> c).map(_ * 2) //   Link   in  c.   map-,      2 val c2 = in.map(_ * 2) //       map.    

मानचित्र, फ्लैटपाइप, फिल्टर विधियों के मानक नामों का उपयोग करने से आप स्काला-चीनी का उपयोग कर सकते हैं - समझ के लिए:

  val c2 = for(i <- in) yield i * 2 //    ,      in.map val c3 = for(i <- in; j <- 0 until i) yield j * 2 // /*    : val temp = in.flatMap(i => 0 until i) val c3 = cc.map(j => j * 2) */ 

DSL का उपयोग करने के अधिक उदाहरणों के लिए, SynapseGrid देखें ।

प्रणाली कायापलट

SynapseGrid में, दो चरणों को स्पष्ट रूप से प्रतिष्ठित किया जाता है - सिस्टम डिज़ाइन चरण और रनटाइम चरण। इसके अलावा, आमतौर पर ये चरण ओवरलैप नहीं होते हैं। केवल एक कार्य प्रणाली में नए तत्वों को जोड़ना संभव नहीं है। इसी तरह की एक घटना होती है, उदाहरण के लिए, गुइसे में - मॉड्यूल पहले बनाए जाते हैं, और फिर, मॉड्यूल में निहित विवरण के अनुसार, एक कार्य प्रणाली का निर्माण किया जाता है।

सिस्टम का निर्माण करने वाला कोड बिल्डर एपीआई का उपयोग करता है। और एक वास्तविक प्रणाली में काम करने वाला कोड संपर्कों और संकेतों के बारे में कुछ भी नहीं जानता है। यह केवल आने वाले डेटा को संसाधित करता है और निष्पादन का परिणाम देता है।

ट्रेलिस, असतत समय, समकालिकता और नियतावाद

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

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

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

यदि आप समय में प्रत्येक क्षण संकेतों के सेट को देखते हैं, तो परिणामी तस्वीर को ट्रेलिस कहा जाता है और इसका उपयोग किया जाता है, उदाहरण के लिए, विटर्बी एल्गोरिथ्म में ।

, .

, . , — (« »).

pipeline . . , . -, , .

. , , :

  type Component = Signal => Collection[Signal] 

यानी , in1, Signal in1. , out1 Signal(out1, data) .

. .

, Akka-.

90% . Akka , . SynapseGrid . , , . .

SynapseGrid

, SynapseGrid, , Akka . अर्थात्:
1. - . ().
2. .
3. , .
4. , .

10% , . , , . .

, 16 ExecutorContext' SynapseGrid. synapse-grid-concurrent .

निष्कर्ष

SynapseGrid , (ASAP) . , . API Builder' . (immutable).

. SynapseGrid Akka , .

GitHub' (BSD-like).

SynapseGrid, .