🤸 👎🏼 🗺️ अपाचे ऊंट के साथ काम करने के लिए उपयोगी ट्रिक्स ➗ 🚴🏿 🔡

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

परिचय

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

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

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

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

हम ActiveMQ का उपयोग संदेश कतार और हेज़ेलकास्ट के रूप में ऑनलाइन संग्रहण के रूप में करते हैं।

स्केलिंग

समानांतर प्रसंस्करण को व्यवस्थित करने के लिए, कई सहकर्मी सर्वरों का एक समूह आयोजित किया जाता है। ActiveMQ ब्रोकर उनमें से प्रत्येक पर रहता है, जिसमें कतार में HTTP प्रोटोकॉल के माध्यम से आने वाले संदेश जोड़े जाते हैं। HTTP हैंडल एक बैलेंसर के पीछे स्थित हैं जो लाइव सर्वर पर संदेश वितरित करता है।

प्रत्येक सर्वर पर इनपुट संदेश कतार को एक कैमल एप्लिकेशन द्वारा पार्स किया जाता है जो राज्यों को संग्रहीत करने के लिए एक हेज़ेलकास्ट क्लस्टर का उपयोग करता है और यदि आवश्यक हो, तो प्रसंस्करण को सिंक्रनाइज़ करें। ActiveMQ भी NetworkConnectors का उपयोग करके क्लस्टर किया गया है, और एक दूसरे के साथ संदेश "साझा" कर सकते हैं।

सामान्य तौर पर, योजना इस प्रकार है:

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

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

वितरित एग्रीगेटर्स

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

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

छिपा हुआ पाठ

public class HazelcastAggregatorRepository implements AggregationRepository { private final Logger logger = LoggerFactory.getLogger(getClass()); // maximum time of waiting for the lock from hz public static final long WAIT_FOR_LOCK_SEC = 20; private final HazelcastInstance hazelcastInstance; private final String repositoryName; private IMap<String, DefaultExchangeHolder> map; public HazelcastAggregatorRepository(HazelcastInstance hazelcastInstance, String repositoryName){ this.hazelcastInstance = hazelcastInstance; this.repositoryName = repositoryName; } @Override protected void doStart() throws Exception { map = hazelcastInstance.getMap(repositoryName); } @Override protected void doStop() throws Exception { /* Nothing to do */ } @Override public Exchange add(CamelContext camelContext, String key, Exchange exchange) { try { DefaultExchangeHolder holder = DefaultExchangeHolder.marshal(exchange); map.tryPut(key, holder, WAIT_FOR_LOCK_SEC, TimeUnit.SECONDS); return toExchange(camelContext, holder); } catch (Exception e) { logger.error("Failed to add new exchange", e); } finally { map.unlock(key); } return null; } @Override public Exchange get(CamelContext camelContext, String key) { try { map.tryLock(key, WAIT_FOR_LOCK_SEC, TimeUnit.SECONDS); return toExchange(camelContext, map.get(key)); } catch (Exception e) { logger.error("Failed to get the exchange", e); } return null; } @Override public void remove(CamelContext camelContext, String key, Exchange exchange) { try { logger.debug("Removing '" + key + "' tryRemove..."); map.tryRemove(key, WAIT_FOR_LOCK_SEC, TimeUnit.SECONDS); } catch (Exception e) { logger.error("Failed to remove the exchange", e); } finally { map.unlock(key); } } @Override public void confirm(CamelContext camelContext, String exchangeId) { /* Nothing to do */ } @Override public Set<String> getKeys() { return Collections.unmodifiableSet(map.keySet()); } private Exchange toExchange(CamelContext camelContext, DefaultExchangeHolder holder) { Exchange exchange = null; if (holder != null) { exchange = new DefaultExchange(camelContext); DefaultExchangeHolder.unmarshal(exchange, holder); } return exchange; } }

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

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

वितरित टाइमर

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

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

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

  <bean id="quartz" class="org.apache.camel.component.quartz.QuartzComponent"> <property name="autoStartScheduler" value="false"/> </bean>

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

 <bean class="com.my.hazelcast.HazelcastQuartzSchedulerStartupListener"> <property name="hazelcastInstance" ref="hazelcastInstance"/> <property name="quartzComponent" ref="quartz"/> </bean>

हमें अनुसूचक आरंभीकरण वर्ग का निम्नलिखित कार्यान्वयन प्राप्त होता है:

छिपा हुआ पाठ

 public class HazelcastQuartzSchedulerStartupListener implements ShutdownPrepared, ApplicationListener { public static final String DEFAULT_QUARTZ_LOCK = "defaultQuartzLock"; protected volatile boolean initialized = false; Logger log = LoggerFactory.getLogger(getClass()); Lock lock; protected volatile boolean initialized = false; protected String lockName; protected HazelcastInstance hazelcastInstance; protected QuartzComponent quartzComponent; public HazelcastQuartzSchedulerStartupListener() { super(); log.info("HazelcastQuartzSchedulerStartupListener created"); } public void setLockName(final String lockName) { this.lockName = lockName; } public synchronized Lock getLock() { if (lock == null) { lock = hazelcastInstance.getLock(lockName != null ? lockName : DEFAULT_QUARTZ_LOCK); } return lock; } @Override public void prepareShutdown(boolean forced) { unlock(); } @Required public void setQuartzComponent(QuartzComponent quartzComponent) { this.quartzComponent = quartzComponent; } @Required public void setHazelcastInstance(HazelcastInstance hazelcastInstance) { this.hazelcastInstance = hazelcastInstance; } @Override public synchronized void onApplicationEvent(ApplicationEvent event) { if (initialized) { return; } try { while (true) { try { getLock().lock(); log.warn("This node is now the master Quartz!"); try { quartzComponent.startScheduler(); } catch (Exception e) { unlock(); throw new RuntimeException(e); } return; } catch (OperationTimeoutException e) { log.warn("This node is not the master Quartz and failed to wait for the lock!"); } } } catch (Exception e) { log.error("Error while trying to wait for the lock from Hazelcast!", e); } } private synchronized void unlock() { try { getLock().unlock(); } catch (IllegalStateException e) { log.warn("Exception while trying to unlock quartz lock: Hazelcast instance is already inactive!"); } catch (Exception e) { log.warn("Exception during the unlock of the master Quartz!", e); } } }

इस प्रकार, हम समय-समय पर कार्यों का उपयोग करने में सक्षम होंगे जैसा कि कैमल द्वारा अनुशंसित और वितरित रनटाइम को ध्यान में रखते हुए। उदाहरण के लिए, इस तरह:

 <route id="quartz-route"> <from uri="quartz://quartz-test/test?cron=*+*+*+*+*+?"/> <log message="Quartz each second message caught ${in.body.class}!"/> <to uri="direct:queue:done-quartz"/> </route>

परिमित राज्य मशीन

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

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

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

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

संक्रमणों का एक सेट @ ट्रान्सनमेंट एनोटेशन और @ ट्रान्सिट एनोटेशन की एक सरणी द्वारा घोषित किया जाता है, जिनमें से प्रत्येक में आप प्रारंभिक राज्यों (से), अंतिम स्थिति () से, उन घटनाओं का एक सेट निर्दिष्ट कर सकते हैं जिनके द्वारा यह संक्रमण सक्रिय (चालू) है, और यह भी इंगित करता है कि क्या यह राज्य है मशीन के अंत (बंद)। प्रसंस्करण बदलाव के लिए, एनोटेशन @OnTransit , @BeforeTransit , और @AfterTransit भी प्रदान किए जाते हैं , जिसके साथ आप क्लास के अंदर सार्वजनिक तरीकों को चिह्नित कर सकते हैं। इन तरीकों को बुलाया जाएगा यदि एक मिलान संक्रमण पाया जाता है जो इसके हस्ताक्षर से मेल खाता है।

 @FSM(start = Undefined.class) @Transitions({ @Transit(on = TestPassed.class, to = TestPassedState.class), @Transit(on = TestFailed.class, to = TestFailedState.class), @Transit(stop = true, on = TestExpired.class), }) public class TestStateFSM { @OnTransit public void onTestFailed(State oldState, TestFailedState newState, TestFailed event){} @OnTransit public void onTestPassed(State oldState, TestPassedState newState, TestPassed event){} }

राज्य मशीन के साथ काम इस प्रकार है:

 Yatomata<TestStateFSM> fsm = new FSMBuilder(TestStateFSM.class).build(); fsm.getCurrentState(); // returns instance of Undefined fsm.isStopped(); // returns false fsm.getFSM(); // returns instance of TestStateFSM fsm.fire(new TestPassed()); // returns instance of TestPassedState fsm.fire(new TestFailed()); // returns instance of TestFailedState fsm.fire(new TestExpired()); // returns instance of TestFailedState fsm.isStopped(); // returns true

एग्रीगेशनस्ट्रेगेटी इंटरफ़ेस लागू करके, हमने FSMAggregationStrategy बनाया, जो स्प्रिंग के संदर्भ में निम्नानुसार घोषित किया गया है:

  <bean id="runnableAggregator" class="com.my.FSMAggregationStrategy"> <constructor-arg value="com.my.TestStateFSM"/> </bean>

इस राज्य मशीन का उपयोग करते समय एकत्रीकरण रणनीति का सबसे सरल कार्यान्वयन इस तरह दिखाई दे सकता है:

छिपा हुआ पाठ

 public class FSMAggregationStrategy<T> implements AggregationStrategy { private final Yatomata<T> fsmEngine; public FSMAggregationStrategy(Class fsmClass) { this.fsmEngine = new FSMBuilder(fsmClass).build(); } @Override public Exchange aggregate(Exchange state, Exchange message) { Object result = state == null ? null : state.getIn().getBody(); try { Object event = message.getIn().getBody(); Object fsm = fsmEngine.getFSM(); result = fsmEngine.fire(event); } catch (Exception e) { logger.error(fsm + " error", e); } if (result != null) { message.getIn().setBody(result); } return message; } public boolean isCompleted() { return fsmEngine.isCompleted(); } }

निष्कर्ष

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

अपाचे ऊंट के साथ काम करने के लिए उपयोगी ट्रिक्स

परिचय

स्केलिंग

वितरित एग्रीगेटर्स

वितरित टाइमर

परिमित राज्य मशीन

निष्कर्ष

More articles: