महत्वपूर्ण-मिशन प्रणाली के लिए एक वितरित एन-उत्पादकों / 1-उपभोक्ता सेवा को लागू करना

Question

मैं एक महत्वपूर्ण-मिशन प्रणाली के लिए बहु-निर्माता / 1-उपभोक्ता के वितरित संस्करण को लागू करने का प्रयास कर रहा हूं। मैं RDBMS पर आधारित वर्तमान दृष्टिकोण के लिए अच्छे विकल्पों की तलाश कर रहा हूं।

समस्या

सिस्टम में सर्वरल (50+) उत्पादक होते हैं जो लगातार प्रति सेकंड हजारों इंस्टेंसेस का उत्पादन करते हैं। प्रत्येक उदाहरण एक अच्छी तरह से परिभाषित, टाइमस्टैम्पड, फ्लैट संरचित है। प्रत्येक उदाहरण को उत्पादकों द्वारा एकल कतार में संग्रहीत किया जाता है।

दूसरे पक्ष में, मेरे पास एक उपभोक्ता है जो एक FIFO तरीके से उदाहरणों का उपभोग करता है।

निर्माता और उपभोक्ता एक टीसीपी / आईपी निजी नेटवर्क द्वारा जुड़ी विभिन्न मशीनों पर चलते हैं।

पूर्णता के लिए, दो मजबूत आवश्यकताएं हैं

1. उपभोक्ता एक ही संसाधन का दो बार उपभोग नहीं कर सकता है। यह एक त्रुटि है।
2. हर संसाधन का उपभोग उपभोक्ता को करना चाहिए। यदि कोई संसाधन छूट जाता है तो यह एक नुकसान है

इसके अलावा, समाधान लिनक्स और विंडोज सर्वर पर चलना चाहिए।

वर्तमान दृष्टिकोण

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

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

डेटाबेस सर्वर / JDBC लेन-देन मॉडल कतार भ्रष्टाचार से बचने के लिए आवेषण / विलोपन को नियंत्रित करने की अनुमति देता है।

यह वर्तमान तरीका अच्छा काम करता है लेकिन:

1. एक कार्य के लिए संपूर्ण रिलेशनल डेटाबेस सर्वर को बनाए रखने के ओवरहेड का परिचय देता है जहां कोई डेटा संबंध आवश्यक नहीं है;
2. रिलेशनल डेटाबेस सर्वर को महत्वपूर्ण-मिशन की आवश्यकताओं के लिए फिट होना चाहिए जो डेटाबेस सर्वर का उदाहरण समर्पित नहीं होने पर कुछ वास्तविक सेटिंग्स पर प्राप्त करना कठिन है।

वैकल्पिक

यहां मैं वर्तमान रिलेशनल डेटाबेस सर्वर डेटा बस दृष्टिकोण के लिए कुछ विकल्प सूचीबद्ध कर रहा हूं:

हल्के रिलेशनल डेटाबेस सर्वर को समर्पित करें

यह सबसे आसान तरीका है: एचएसक्यूएलडीबी, अपाचे डर्बी या एच 2 के रूप में एक समर्पित हल्के संबंधपरक डेटाबेस सर्वर का उपयोग करना।

पेशेवरों

यदि कोई RDBMS जैसे MS SQL सर्वर, Oracle DB सर्वर या यहां तक ​​कि MySQL के साथ तुलना करने पर उन्हें बनाए रखने के लिए काफी कम ओवरहेड है। इसके अलावा, कम कोड परिवर्तन और परीक्षण आवश्यक हैं क्योंकि वे मूल रूप से SQL इंजन हैं जैसे कि वर्तमान समाधान में उपयोग किए गए हैं।

विपक्ष

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

रेडिस सर्वर

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

खरोंच से एक समाधान को लागू करना

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

ये ऐसे विकल्प हैं जिन पर हम अब तक विचार कर रहे हैं। मैं सराहना करता हूं कि कोई व्यक्ति कुछ अंतर्दृष्टि या सिफारिश प्रदान कर सकता है।

Answer 1

लगता है कि आप एक संदेश कतार के लिए देख रहे हैं। आपके तकनीकी स्टैक के आधार पर, वितरित कतार के विभिन्न कार्यान्वयन हैं जो आपको रुचि दे सकते हैं, उदाहरण के लिए ZeroMQ या RabbitMQ।

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

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

रिश्ता-मुक्त कार्य करने के लिए अभी भी कुछ स्तर उपरि मौजूद हैं

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