🌋 🥖 🔱 प्रस्तुत है स्प्रिंग में प्रतिक्रियाशील प्रोग्रामिंग 👨‍🎤 🏘️ 👨‍⚕️

नमस्कार, हेब्र!

इस हफ्ते हम प्रिंटिंग हाउस से एक नई स्प्रिंग 5 बुक की उम्मीद कर रहे हैं:

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

मैट को जोश लॉन्ग द्वारा सह-लेखक किया गया था, जो जावा और स्प्रिंग के बारे में एक और महान पुस्तक, " जावा इन द क्लाउड " के लेखक थे , जिसे पिछली गर्मियों में रिलीज़ किया गया था।

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

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

प्रतिक्रियाशील प्रोग्रामिंग या I / O, I / O, हम काम पर जाते हैं ...

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

विचार करें कि सिंक्रोनस और एसिंक्रोनस इनपुट / आउटपुट के बीच क्या सामान्य है, और उनके बीच क्या अंतर हैं।

हम एक सरल प्रोग्राम लिखेंगे जो स्रोत से डेटा पढ़ता है (विशेष रूप से, हम java.io.File लिंक के बारे में बात कर रहे हैं)। आइए एक कार्यान्वयन के साथ शुरू करें जो अच्छे पुराने java.io.InputStream का उपयोग करता है:

उदाहरण 1. किसी फ़ाइल से डेटा को सिंक्रोनाइज़ करना

 package com.example.io; import lombok.extern.log4j.Log4j2; import org.springframework.util.FileCopyUtils; import java.io.File; import java.io.FileInputStream; import java.io.IOException; import java.util.function.Consumer; @Log4j2 class Synchronous implements Reader { @Override public void read(File file, Consumer<BytesPayload> consumer) throws IOException { try (FileInputStream in = new FileInputStream(file)) { //1 byte[] data = new byte[FileCopyUtils.BUFFER_SIZE]; int res; while ((res = in.read(data, 0, data.length)) != -1) { //2 consumer.accept(BytesPayload.from(data, res)); //3 } } } }

हम सामान्य java.io.File साथ पढ़ने के लिए एक फ़ाइल प्रदान करते हैं
एक समय में स्रोत एक पंक्ति से परिणाम खींचें ...
मैंने यह कोड Consumer<BytesPayloadgt; लेने के लिए लिखा था Consumer<BytesPayloadgt; नया डेटा आने पर कॉल किया जाता है

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

लेकिन, अगर हम डेटा को File से नहीं, बल्कि नेटवर्क सॉकेट से पढ़ते हैं, और InputStream दूसरे कार्यान्वयन का उपयोग करते हैं, तो क्या होता है? चिंता की कोई बात नहीं! बेशक, अगर नेटवर्क की गति असीम रूप से अधिक है, तो चिंता करने की कोई बात नहीं होगी। और अगर इस और दूसरे नोड के बीच नेटवर्क चैनल कभी विफल नहीं होता है। यदि ये शर्तें पूरी होती हैं, तो कोड पूरी तरह से काम करेगा।

लेकिन अगर नेटवर्क धीमा हो जाता है या लेट हो जाता है तो क्या होता है? इस स्थिति में, मेरा मतलब है कि ऑपरेशन के in.read(…) तक हम अवधि in.read(…) । वास्तव में, वह वापस नहीं आ सकती है! यह एक समस्या है अगर हम उस धारा के साथ कुछ और करने की कोशिश करते हैं जिससे हम डेटा पढ़ रहे हैं। बेशक, आप हमेशा एक और स्ट्रीम बना सकते हैं और इसके माध्यम से डेटा पढ़ सकते हैं। यह कुछ बिंदु तक किया जा सकता है, लेकिन, अंत में, हम उस सीमा तक पहुंच जाएंगे, जिस पर बस आगे स्केलिंग के लिए धागे जोड़ना अब पर्याप्त नहीं होगा। हमारी मशीन पर मौजूद कोर की संख्या से आगे हमारी सच्ची प्रतिस्पर्धा नहीं होगी। मृत अंत! इस मामले में, हम अतिरिक्त प्रवाह के कारण केवल इनपुट / आउटपुट प्रोसेसिंग (रीडिंग का मतलब यहां है) बढ़ा सकते हैं, लेकिन यहां हम जल्द या बाद में सीमा तक पहुंच जाएंगे।

इस उदाहरण में, काम का मुख्य टुकड़ा पढ़ रहा है - अन्य मोर्चों पर लगभग कुछ भी नहीं होता है। हम I / O पर निर्भर हैं विचार करें कि कैसे एक अतुल्यकालिक समाधान हमारे प्रवाह के एकाधिकार को आंशिक रूप से दूर करने में हमारी मदद करता है।

उदाहरण 2. एक फ़ाइल से अतुल्यकालिक रूप से डेटा पढ़ना

 package com.example.io; import lombok.extern.log4j.Log4j2; import org.springframework.util.FileCopyUtils; import java.io.File; import java.io.IOException; import java.nio.ByteBuffer; import java.nio.channels.AsynchronousFileChannel; import java.nio.channels.CompletionHandler; import java.nio.file.Path; import java.nio.file.StandardOpenOption; import java.util.Collections; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.function.Consumer; @Log4j2 class Asynchronous implements Reader, CompletionHandler<Integer, ByteBuffer> { private int bytesRead; private long position; private AsynchronousFileChannel fileChannel; private Consumer<BytesPayload> consumer; private final ExecutorService executorService = Executors.newFixedThreadPool(10); public void read(File file, Consumer<BytesPayload> c) throws IOException { this.consumer = c; Path path = file.toPath(); // 1 this.fileChannel = AsynchronousFileChannel.open(path, Collections.singleton(StandardOpenOption.READ), this.executorService); //2 ByteBuffer buffer = ByteBuffer.allocate(FileCopyUtils.BUFFER_SIZE); this.fileChannel.read(buffer, position, buffer, this); //3 while (this.bytesRead > 0) { this.position = this.position + this.bytesRead; this.fileChannel.read(buffer, this.position, buffer, this); } } @Override public void completed(Integer result, ByteBuffer buffer) { //4 this.bytesRead = result; if (this.bytesRead < 0) return; buffer.flip(); byte[] data = new byte[buffer.limit()]; buffer.get(data); //5 consumer.accept(BytesPayload.from(data, data.length)); buffer.clear(); this.position = this.position + this.bytesRead; this.fileChannel.read(buffer, this.position, buffer, this); } @Override public void failed(Throwable exc, ByteBuffer attachment) { log.error(exc); } }

इस बार हम Java NIO java.nio.file.Path बनाने से java.io.File अनुकूलित करते हैं
Channel बनाते समय, हम, विशेष रूप से, java.util.concurrent.ExecutorService सेवा निर्दिष्ट करते हैं, जिसका उपयोग आवश्यक डेटा प्रकट होने पर CompletionHandler हैंडलर को कॉल करने के लिए किया जाएगा
हम CompletionHandler<Integer, ByteBuffer> (this) लिंक पास करके पढ़ना शुरू करते हैं
कॉलबैक में, बाइट से बाइट्स को byte[] क्षमता में पढ़ें byte[]
जैसे Synchronous उदाहरण में, byte[] डेटा उपभोक्ता को दिया जाता है।

हम तुरंत आरक्षण कर देंगे: यह कोड बहुत कठिन हो गया है! यहाँ पर बहुत सारी चीज़ें चल रही हैं, जो कि आपका सिर एकदम से घूम रही हैं, हालाँकि, मुझे यह बताना चाहिए ... यह कोड Java NIO Channel डेटा को पढ़ता है, और फिर कॉलबैक के लिए जिम्मेदार एक अलग थ्रेड में इस डेटा को प्रोसेस करता है। इस प्रकार, जिस स्ट्रीम में पढ़ना शुरू किया गया है उसका एकाधिकार नहीं है। हम कॉल .read(..) बाद लगभग तुरंत वापस लौट आते हैं .read(..) , और जब, अंत में, हमारे पास हमारे निपटान में डेटा होता है, एक कॉलबैक किया जाता है - पहले से ही एक और धागे में। यदि .read() कॉल के बीच विलंब होता है .read() तो आप उन्हें हमारे थ्रेड में निष्पादित करके अन्य मामलों में आगे बढ़ सकते हैं। एक अतुल्यकालिक रीड ऑपरेशन की अवधि, पहले बाइट से लेकर अंतिम तक, सिंक्रोनस रीड ऑपरेशन की तुलना में सबसे अच्छा नहीं है। आमतौर पर, एक अतुल्यकालिक ऑपरेशन अब नगण्य है। हालांकि, ऐसी अतिरिक्त कठिनाइयों के लिए, हम अपने प्रवाह को अधिक प्रभावी ढंग से संभाल सकते हैं। अधिक काम करें, थ्रेड की एक सीमित संख्या के साथ एक पूल में I / O को मल्टीप्लेक्स करें।

मैं क्लाउड कंप्यूटिंग कंपनी के लिए काम करता हूं। हम आपको क्षैतिज स्केलिंग के साथ समस्याओं को हल करने के लिए आवेदन के नए उदाहरण प्राप्त करना चाहते हैं! बेशक, यहां मैं थोड़ा असंतुष्ट हूं। एसिंक्रोनस I / O चीजों को थोड़ा जटिल करता है, लेकिन मुझे आशा है कि यह उदाहरण दिखाता है कि प्रतिक्रियाशील कोड कितना उपयोगी है: यह आपको अधिक अनुरोधों को संसाधित करने और अपने मौजूदा हार्डवेयर पर अधिक काम करने की अनुमति देता है यदि प्रदर्शन I / O पर अत्यधिक निर्भर है। यदि प्रदर्शन प्रोसेसर के उपयोग पर निर्भर करता है (कहते हैं, हम फाइबोनैचि संख्याओं, बिटकॉइन के खनन या क्रिप्टोग्राफी पर संचालन के बारे में बात कर रहे हैं), तो प्रतिक्रियाशील प्रोग्रामिंग हमें कुछ भी नहीं देगा।

वर्तमान में, हम में से अधिकांश अपने दैनिक कार्य में Channel या InputStream कार्यान्वयन का उपयोग नहीं करते हैं! हमें उच्च-स्तरीय अमूर्तताओं के स्तर पर समस्याओं के बारे में सोचना होगा। यह सरणियों, या बल्कि, java.util.Collection पदानुक्रम जैसी चीजों के बारे में है। java.util.Collection संग्रह एक इनपुटस्ट्रीम पर बहुत अच्छी तरह से प्रदर्शित होता है: दोनों संस्थाएं मानती हैं कि आप एक बार में सभी डेटा पर काम कर सकते हैं, और लगभग तुरंत। यह उम्मीद की जाती है कि आप पहले के बजाय ज्यादातर InputStreams से रीडिंग खत्म कर पाएंगे। बड़ी मात्रा में डेटा ले जाने पर संग्रह प्रकार थोड़ा असहज हो जाते हैं। क्या होगा यदि आप कुछ संभावित अंतहीन (असीमित) के साथ काम कर रहे हैं - उदाहरण के लिए, वेब सॉकेट या सर्वर इवेंट? रिकॉर्डिंग के बीच देरी होने पर क्या करें?

इस तरह के डेटा का वर्णन करने के लिए हमें एक बेहतर तरीका चाहिए। हम अतुल्यकालिक घटनाओं के बारे में बात कर रहे हैं, जैसे कि अंत में घटित होगी। ऐसा लग सकता है कि Future<T> या CompletableFuture<T> इस उद्देश्य के लिए अच्छी तरह से अनुकूल हैं, लेकिन वे केवल एक चीज का वर्णन करते हैं जो अंत में होता है। वास्तव में, जावा इस तरह के डेटा का वर्णन करने के लिए एक उपयुक्त रूपक प्रदान नहीं करता है। Java 8 से Iterator और Stream दोनों प्रकार असंबंधित हो सकते हैं, हालाँकि, दोनों खींचने के लिए उन्मुख हैं; आप स्वयं अगली प्रविष्टि का अनुरोध करते हैं, न कि प्रकार को आपके कोड पर कॉलबैक भेजना चाहिए। यह माना जाता है कि अगर इस मामले में पुश-आधारित प्रसंस्करण का समर्थन किया गया था, जो थ्रेड स्तर पर बहुत अधिक प्राप्त करने की अनुमति देगा, तो एपीआई थ्रेडिंग और शेड्यूलिंग नियंत्रण भी प्रदान करेगा। Iterator कार्यान्वयन थ्रेडिंग के बारे में कुछ नहीं कहते हैं, और सभी जावा 8 धागे एक ही कांटा-जुड़ने वाले पूल को साझा करते हैं।

यदि Iterator और Stream वास्तव में धक्का प्रसंस्करण का समर्थन करते हैं, तो हम एक और समस्या का सामना करेंगे, जो कि I / O के संदर्भ में वास्तव में सटीक रूप से समाप्त हो गया है: हमें किसी प्रकार के बैक पैठ तंत्र की आवश्यकता है! चूंकि डेटा उपभोक्ता को अतुल्यकालिक रूप से संसाधित किया जाता है, इसलिए हमें पता नहीं है कि डेटा कब पाइपलाइन में और किस मात्रा में होगा। हमें नहीं पता कि अगले कॉलबैक में कितना डेटा संसाधित करना होगा: एक बाइट या एक टेराबाइट!

एक InputStream से डेटा खींचते हुए, आप उतनी ही जानकारी पढ़ते हैं जितनी आप प्रोसेस करने के लिए तैयार हैं, और इससे अधिक नहीं। पिछले उदाहरणों में, हम डेटा को byte[] एक निश्चित और ज्ञात लंबाई के बफर में पढ़ते हैं। एक अतुल्यकालिक संदर्भ में, हमें प्रदाता को यह बताने के लिए किसी तरह की आवश्यकता है कि हम कितना डेटा संसाधित करने के लिए तैयार हैं।
जी, सर। यहाँ कुछ याद आ रहा है।

लापता रूपक की खोज करें

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

अब कई अच्छी परियोजनाएं हैं - Vert.x, Akka Streams और RxJava - प्रतिक्रियाशील प्रोग्रामिंग का समर्थन। स्प्रिंग टीम रिएक्टर नामक एक परियोजना भी चलाती है। इन विभिन्न मानकों के बीच एक काफी व्यापक सामान्य क्षेत्र है, डी रिएक्टिव स्ट्रीम पहल मानक को आवंटित किया गया है। प्रतिक्रियाशील धाराओं की पहल चार प्रकारों को परिभाषित करती है:

Publisher<T> इंटरफ़ेस Publisher<T> ; उन मूल्यों का उत्पादन करता है जो अंततः आ सकते हैं। Publisher<T> इंटरफ़ेस Publisher<T> ; Subscriber<T> लिए टाइप T का मान बनाता है।

उदाहरण 3. प्रतिक्रियाशील धाराएँ: Publisher<T> इंटरफ़ेस ।

 package org.reactivestreams; public interface Publisher<T> { void subscribe(Subscriber<? super Tgt; s); }

Subscriber प्रकार Publisher<T> की Subscriber लेता है, जो अपने onNext(T) पद्धति के माध्यम से टाइप T के किसी भी नए मूल्यों की सूचना प्राप्त करता है। यदि कोई त्रुटि होती है, तो इसका onError(Throwable) तरीका onError(Throwable) । जब प्रसंस्करण सामान्य रूप से पूरा हो जाता है, तो सब्सक्राइबर का onComplete विधि कहा जाता है।

उदाहरण 4. जेट स्ट्रीम: Subscriber<T> इंटरफ़ेस।

 package org.reactivestreams; public interface Subscriber<T> { public void onSubscribe(Subscription s); public void onNext(T t); public void onError(Throwable t); public void onComplete(); }

जब Subscriber पहली बार Publisher जुड़ता है, तो उसे Subscriber#onSubscribe में Subscription मिलता है। सब्सक्रिप्शन Subscription शायद पूरे विनिर्देश का सबसे महत्वपूर्ण हिस्सा है; यह वह है जो रिटर्न फ्लो प्रदान करता है। एक सब्सक्राइबर सब्सक्राइबर अतिरिक्त डेटा का Subscription#request करने के लिए Subscription#request विधि का उपयोग करता है या प्रोसेसिंग रोकने के लिए Subscription#cancel विधि का उपयोग करता है।

उदाहरण 5. प्रतिक्रियाशील धाराएँ: Subscription<T> इंटरफ़ेस ।

 package org.reactivestreams; public interface Subscription { public void request(long n); public void cancel(); }

प्रतिक्रियाशील स्ट्रीम विनिर्देश एक और उपयोगी, यद्यपि स्पष्ट, प्रकार प्रदान करता है: Processor<A,B> केवल एक इंटरफ़ेस है जो Subscriber<A> और Publisher<B> दोनों को विरासत में मिला है।

उदाहरण 6. जेट स्ट्रीम: Processor<T> इंटरफ़ेस ।

 package org.reactivestreams; public interface Processor<T, R> extends Subscriber&ltT>, Publisher<R> { }

एक विनिर्देश कार्यान्वयन के लिए एक नुस्खे के रूप में तैनात नहीं है, वास्तव में, इसका उद्देश्य इंटरऑपरेबिलिटी का समर्थन करने के लिए प्रकारों को परिभाषित करना है। प्रतिक्रियाशील प्रवाह से जुड़े प्रकारों का स्पष्ट लाभ यह है कि फिर भी उन्हें जावा 9 रिलीज़ में एक जगह मिली, इसके अलावा, शब्दार्थ वे "एक से एक" java.util.concurrent.Flow वर्ग से इंटरफेस के अनुरूप हैं। उदाहरण के लिए: java.util.concurrent.Flow.Publisher

मिलिए रिएक्टर से

अकेले प्रतिक्रियाशील धाराओं के प्रकार पर्याप्त नहीं हैं; उच्च क्रम कार्यान्वयन को फ़िल्टरिंग और परिवर्तन जैसे संचालन का समर्थन करने की आवश्यकता होती है। जैसे, रिएक्टर परियोजना सुविधाजनक है; यह प्रतिक्रियाशील धाराओं के विनिर्देश पर बनाता है और दो Publisher<T> विशेषज्ञता प्रदान करता है।

सबसे पहले, Flux<T> एक Publisher है जो शून्य या अधिक मूल्यों का उत्पादन करता है। दूसरा, Mono<T> , Publisher<T> , जो शून्य या एक मूल्य का उत्पादन करता है। दोनों ही मूल्यों को प्रकाशित करते हैं और तदनुसार उन्हें संभाल सकते हैं, हालांकि, उनकी क्षमताएं प्रतिक्रियाशील धाराओं के विनिर्देश से बहुत व्यापक हैं। दोनों ही ऐसे ऑपरेटर प्रदान करते हैं जो आपको मूल्य धाराओं को संसाधित करने की अनुमति देते हैं। रिएक्टर प्रकार अच्छी तरह से रचना करते हैं - उनमें से एक का आउटपुट दूसरे के लिए इनपुट के रूप में काम कर सकता है, और यदि एक प्रकार को अन्य डेटा धाराओं के साथ काम करने की आवश्यकता होती है, तो वे Publisher<T> उदाहरणों पर भरोसा करते हैं।

Mono<T> और Flux<T> दोनों Publisher<T> लागू करें Publisher<T> ; हम अनुशंसा करते हैं कि आपके तरीके Publisher<T> उदाहरणों को स्वीकार करते हैं लेकिन Flux<T> या Mono<T> लौटाते हैं; इससे क्लाइंट को यह पता लगाने में मदद मिलेगी कि उसे किस तरह का डेटा मिलता है।

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

बदले में, Flux<T> और Mono<T> बहुत विशिष्ट हैं। आपको पता है कि अगर आपको Flux<T> प्राप्त होता है, तो एक समीक्षा पृष्ठ प्रदर्शित करने की आवश्यकता होती Flux<T> , और Mono<T> प्राप्त करते समय एक विवरण (या एक भी नहीं) रिकॉर्ड के साथ एक पृष्ठ।

रिएक्टर एक ओपन सोर्स प्रोजेक्ट है जिसे Pivotal द्वारा लॉन्च किया गया है; अब वह बहुत लोकप्रिय हो गया है। फेसबुक दूरस्थ प्रक्रियाओं को कॉल करने के लिए अपने जेट इंजन में इसका उपयोग करता है, और RxJava निर्माता बेन क्रिस्टेंसन के नेतृत्व में रोसकेट में भी इसका उपयोग करता है। Salesforce अपने प्रतिक्रियाशील gRPC कार्यान्वयन में इसका उपयोग करता है। रिएक्टर रिएक्टिव स्ट्रीम्स प्रकारों को लागू करता है, इसलिए यह अन्य तकनीकों के साथ बातचीत कर सकता है जो इन प्रकारों का समर्थन करते हैं, उदाहरण के लिए, नेटफ्लिक्स से RxJava 2 के साथ, लाइटबेंड से अक्का स्ट्रीम्स और Esese फाउंडेशन से वर्टैक्स प्रोजेक्ट के साथ। RxJava 2 के निदेशक डेविड केयर्नॉक ने भी रिएक्टर को विकसित करने के लिए Pivotal के साथ सक्रिय रूप से सहयोग किया, जिससे परियोजना और भी बेहतर हो गई। प्लस, निश्चित रूप से, यह स्प्रिंग फ्रेमवर्क 4.0 के साथ शुरू होने वाले स्प्रिंग फ्रेमवर्क में एक या दूसरे रूप में मौजूद है।

स्प्रिंग वेबफ्लक्स के साथ प्रतिक्रियाशील प्रोग्रामिंग

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

स्प्रिंग फ्रेमवर्क 5.0 सितंबर 2017 में जारी किया गया था। यह रिएक्टर और रिएक्टिव स्ट्रीम विनिर्देश पर बनाता है। इसमें एक नया प्रतिक्रियाशील रनटाइम और घटक मॉडल है जिसे स्प्रिंग वेबफ्लक्स कहा जाता है।

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

प्रस्तुत है स्प्रिंग में प्रतिक्रियाशील प्रोग्रामिंग

More articles: