5

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

मुझे पहले कभी ऐसा कुछ भी सौदा नहीं करना पड़ा, लेकिन कुछ पढ़ने से पता चलता है कि यह एक प्रसिद्ध समस्या है।

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

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

क्रॉस पोस्टिंग के लिए क्षमा - यह पहली बार पोस्ट किया गया था स्टैक-एक्सचेंज लेकिन मैंने सवाल में जोड़ा है और यह संस्करण शायद

उत्तर

9

1) 2 phase commit गलती सहनशील नहीं है - लिंक देखें। आप जिस समस्या को हल कर रहे हैं उसके सटीक फॉर्मूलेशन के आधार पर आपको या तो total order broadcast, या एक गैर-अवरुद्ध परमाणु प्रतिबद्धता की आवश्यकता है।

2) मैं यह नहीं कहूंगा कि स्काला दो चरणों के प्रतिबद्धता को लागू करने के लिए अन्य सामान्य प्रयोजन भाषाओं की तुलना में अधिक उपयुक्त है। विशेष रूप से, STMs, parallel और distributed संग्रह आपको यहां सहायता नहीं करेंगे। स्कैला actors and remote actors आपको एसिंक्रोनस (उसी मशीन या दूरस्थ रूप से) के आसपास संदेशों को भेजने के लिए एक अच्छा एपीआई प्रदान कर सकता है, लेकिन वे डिफ़ॉल्ट रूप से आपको विभिन्न विफलता डिटेक्टरों जैसे अवशोषण नहीं देते हैं जो कुल ऑर्डर ब्रॉडकास्ट को लागू करने के लिए उपयोगी होंगे, उदाहरण के लिए - आपको अभी भी इन्हें स्वयं लागू करना होगा (दूसरी ओर, मेरा मानना ​​है कि Akka में इन अवशेष हैं)।

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

+2

बहुत उपयोगी उत्तर - धन्यवाद और +1। मुझे अभी भी यह देखने में दिलचस्पी है कि इसे स्वीकार करने से पहले अन्य विचार क्या हैं – chrispanda