क्वेक चैंपियंस के बैकएंड प्लेटफॉर्म में अभिनेता मॉडल का उपयोग करने की प्रथा

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


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

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



फिलहाल, हम Azure में अपनी सेवाओं की मेजबानी करते हैं। कुछ बहुत ही रोचक आदिम हैं जिन्हें हम छोड़ना नहीं चाहते हैं, जैसे टेबल स्टोरेज और कॉसमॉस डीबी (लेकिन हम क्रॉस-प्लेटफॉर्म प्रोजेक्ट की खातिर उन पर ज्यादा तंग न होने की कोशिश करते हैं)।

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



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

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

थोड़ा ऊपर उठते हुए, आइए कल्पना करें कि हमारे पास एक ऐसा क्लाउड है जहां किसी प्रकार का सर्वर क्लस्टर है, और हमारे कलाकार इस क्लस्टर में घूम रहे हैं।



अभिनेता एक दूसरे से अलग-थलग हैं, अतुल्यकालिक कॉल के माध्यम से संवाद करते हैं, और खुद के अंदर, अभिनेता थ्रेड सुरक्षित हैं।

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



हम अपने क्लाउड में सर्वर जोड़ सकते हैं और, अभिनेता मॉडल का उपयोग करके, अलग-अलग उपयोगकर्ताओं को धक्का दे सकते हैं - प्रत्येक व्यक्तिगत अभिनेता को असाइन करें और क्लाउड में इस अभिनेता के लिए मेमोरी और प्रोसेसर समय के लिए स्थान आवंटित करें।

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

हम बैकएंड में क्लासिक अभिनेता मॉडल का उपयोग नहीं करते हैं, लेकिन ऑरलियन्स ढांचे के आधार पर। क्या अंतर है - मैं अब आपको बताने की कोशिश करूंगा।



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

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



इससे हमें क्या लाभ मिलता है? सबसे पहले, पारदर्शी लोड संतुलन इस तथ्य के कारण है कि प्रोग्रामर को खुद अभिनेता के स्थान को प्रबंधित करने की आवश्यकता नहीं है। वह बस ऑरलियन्स कहता है, जो कई सर्वरों पर तैनात है: मुझे अपने सर्वर से ऐसे अभिनेता दें।



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

दूसरे, ऑरलियन्स सर्वर क्रैश को हैंडल करता है।



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

इसे थोड़ा और स्पष्ट करने के लिए, आइए एक छोटे से उदाहरण पर ध्यान दें कि उपयोगकर्ता अपने राज्य में कुछ कैसे पढ़ता है।



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

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

यदि हमारे पास कई क्लाइंट (गेम क्लाइंट, गेम सर्वर) हैं, तो वे उपयोगकर्ता राज्यों से अनुरोध कर सकते हैं, और उनमें से एक इस अनाज को उठाएगा। अधिक सटीक रूप से, यह ऑरलियन्स इसे उठाएगा, और फिर सभी कॉल, जैसा कि हम पहले से ही जानते हैं, इसमें धागा-सुरक्षित, क्रमिक रूप से होता है। सबसे पहले, क्लाइंट राज्य प्राप्त करेगा, और फिर गेम सर्वर।



अद्यतन पर समान प्रवाह। जब कोई ग्राहक राज्य को अपडेट करना चाहता है, तो वह इस जिम्मेदारी को अनाज में स्थानांतरित कर देगा, अर्थात। उसे बताएंगे: "इस उपयोगकर्ता को 10 सोना दें", और अनाज उगता है, यह अनाज के अंदर कुछ प्रकार के व्यापारिक तर्क के साथ इस राज्य को संसाधित करता है। और फिर आता है कैश कैश का अपडेट और, अगर वांछित है, दृढ़ता में दृढ़ता।



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

सबसे सरल मामला: हर सेव स्टेट कॉल के लिए, इस अपडेट को Persistence पर लिखें। इस प्रकार, अगर ग्रे अचानक अप्रत्याशित रूप से गिरता है, तो कुछ अन्य सर्वरों पर गाइने का अगला उठाना वर्तमान डेटा के साथ कैश अपडेट का कारण होगा।

यह कैसा दिखता है इसका एक छोटा सा उदाहरण।



जैसा कि मैंने पहले ही कहा, एक अनाज में एक प्रकार और कुछ कुंजी होती है (इस मामले में, प्रकार IPlayerState है, कुंजी IGrainWithGuidKey है, जिसका अर्थ है कि यह मार्गदर्शिका है)। और हमारे पास एक इंटरफ़ेस है जिसे हम लागू करते हैं, अर्थात्। GetStates राज्यों और ApplyState की कुछ सूची देता है, जो कुछ राज्य लागू करते हैं। ऑरलियन्स के तरीके टास्क लौटाते हैं। इसका क्या अर्थ है: कार्य एक वादा है जो हमें बताता है कि जब राज्य वापस आ जाता है, तो यह वादा सुलझी हुई स्थिति में होगा। हमारे पास कुछ प्लेयरस्टैट भी हैं जो हमें ग्रेनफैक्ट्री के साथ मिलते हैं। यानी यहाँ हमें एक लिंक मिलता है, और हम इस अनाज के भौतिक स्थान के बारे में कुछ भी नहीं जानते हैं। गेटस्टेट्स को कॉल करते समय, ऑरलियन्स हमारे ग्रेन को बढ़ाएंगे, पर्सिस्टेंस स्टोर से स्टेट को उसकी मेमोरी में पढ़ेंगे, और जब अपस्टैट एक नया राज्य लागू करेगा, तो यह अपनी मेमोरी और पर्सिस्टेंस में भी इस स्थिति को अपडेट करेगा।

मैं हमारी UserStates सेवा के उच्च स्तर के आर्किटेक्चर पर कुछ अधिक जटिल उदाहरण बनाना चाहता हूं।



हमारे पास कुछ प्रकार के गेम क्लाइंट हैं जो अपने राज्यों को OfferSevice के माध्यम से प्राप्त करते हैं। हमारे पास एक GameConfigurationService है, जो इस मामले में हमारे उपयोगकर्ता के आर्थिक मॉडल के लिए जिम्मेदार है। और हमारे पास एक ऑपरेटर है जो इस आर्थिक मॉडल को बदल रहा है। इसके अनुसार, उपयोगकर्ता अपने राज्यों को प्राप्त करने के लिए एक ऑफ़रवेसिस का अनुरोध करता है। और OfferSevice पहले से ही UserOrleans सेवा को एक्सेस कर रहा है, जिसमें ये अनाज शामिल हैं, यह अपनी मेमोरी में उपयोगकर्ता की इस स्थिति को बढ़ाता है, संभवतः किसी प्रकार के व्यावसायिक तर्क को निष्पादित करता है, और डेटा को वापस OfferService के माध्यम से उपयोगकर्ता को लौटाता है।

सामान्य तौर पर, मैं इस तथ्य पर ध्यान आकर्षित करना चाहूंगा कि ऑरलियन्स इस तथ्य के कारण उच्च समानता की क्षमता के लिए अच्छा है कि अनाज एक दूसरे से स्वतंत्र हैं। और दूसरी ओर, जाइन्स के अंदर, हमें सिंक्रोनाइजेशन प्राइमेटिव्स का उपयोग करने की आवश्यकता नहीं है, क्योंकि हम जानते हैं कि इस गीनर को प्रत्येक कॉल किसी न किसी तरह से संगत होगा।

यहाँ मैं इस मॉडल के कुछ नुकसान को दूर करना चाहूंगा।



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

दूसरी समस्या इतनी स्पष्ट नहीं है - यह तथाकथित श्रृंखला प्रतिक्रिया है। जब कोई उपयोगकर्ता कुछ अनाज उठाता है, और वह बदले में, सिस्टम में अन्य अनाज को बढ़ा सकता है। यह कैसे होता है: उपयोगकर्ता अपनी स्थिति प्राप्त करता है, और उपयोगकर्ता के मित्र होते हैं और वह अपने दोस्तों की स्थिति प्राप्त करता है। इस प्रकार, पूरी प्रणाली अपने सभी अनाज को स्मृति में रखती है, और यदि हमारे पास 1000 उपयोगकर्ता हैं, और प्रत्येक के 100 दोस्त हैं, तो 100,000 अनाज उसी तरह सक्रिय हो सकते हैं। इस मामले से भी बचने की जरूरत है - किसी तरह दोस्तों की राज्यों को किसी तरह की साझा मेमोरी में स्टोर करें।



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

श्रोताओं से सवाल

- आप CICD जैसी क्लासिक समस्याओं को कैसे हल करते हैं, इन अभिनेताओं को अपडेट करते हुए, क्या आप डॉकटर का उपयोग करते हैं और क्या इसकी आवश्यकता है?

- हम अभी तक डॉकटर का उपयोग नहीं कर रहे हैं। सामान्य तौर पर, DevOps परिनियोजन में लगे होते हैं, वे हमारी सेवाओं को Azure क्लाउड सेवा में तैनात करते हैं।

- निरंतर अद्यतन, बिना डाउनटाइम्स के, यह कैसे होता है? ऑरलियन्स खुद तय करते हैं कि सर्वर किस सर्वर पर जाएगा, किस सर्वर से रिक्वेस्ट जाएगी और इस सर्विस को कैसे अपडेट किया जाएगा। यानी एक नया व्यापार तर्क सामने आया है, उसी अभिनेता का एक अपडेट सामने आया है - ये अपडेट कैसे रोल किए गए हैं?

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

"ऑरलियन्स कैसे समझता है कि सर्वर क्रैश हो गया है?" आपने कहा कि वह अभिनेताओं को जल्दी से किसी अन्य सर्वर पर फेंक देता है ...

- उसके पास एक पिंगेटर है जो समय-समय पर समझता है कि कौन से सर्वर जीवित हैं।

- क्या वह किसी अभिनेता या सर्वर को विशेष रूप से पिंग करता है?

- विशेष रूप से, सर्वर।

- ऐसा सवाल: अभिनेता के अंदर एक त्रुटि हुई, आप कहते हैं कि वह कदम से कदम, प्रत्येक निर्देश। लेकिन एक त्रुटि हुई और अभिनेता का क्या हुआ? मान लीजिए कि कोई त्रुटि है जो संसाधित नहीं है। क्या अभिनेता सिर्फ मर रहा है?

- नहीं, ऑरलियन्स मानक .NET स्कीमा में एक अपवाद फेंकता है।

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

- यह निर्भर करता है कि यह किस केस पर निर्भर करता है। उदाहरण के लिए रिट्रीएबल या रिट्रीएबल नहीं।

- यानी। क्या यह सब विन्यास योग्य है?

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

- क्या आपके पास कई दृढ़ता हैं - क्या यह डेटाबेस की तरह है?

- दृढ़ता, हाँ, लगातार भंडारण वाला एक डेटाबेस।

- मान लीजिए कि एक डेटाबेस ने (सशर्त रूप से) गेम मनी रखी है। यदि कोई अभिनेता उसके पास नहीं पहुँच सकता है तो क्या होगा? आप इसे कैसे संभालते हैं?

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

- अगर अभिनेता को स्टोरेज में कुछ नहीं मिला, तो खिलाड़ी कैसा दिखता है? उसके पास बस यह पैसा नहीं है या वह तुरंत खेल को बंद कर देता है?

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

- यह मुझे प्रतीत हुआ कि अभिनेताओं के संदेश अतुल्यकालिक कतारों के माध्यम से होते हैं। यह अनुकूलित समाधान कैसे है? क्या यह प्रफुल्लित नहीं है, क्या यह खिलाड़ी को लटका नहीं सकता है? क्या प्रतिक्रियात्मक दृष्टिकोण का उपयोग करना बेहतर नहीं है?

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

- और इससे खिलाड़ी पर क्या असर पड़ेगा?

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

- यानी। क्या आपको डीडीओएस का खतरा है? बड़ी संख्या में छोटे कार्य एक खिलाड़ी डाल सकते हैं? मान लें कि कोई व्यक्ति मित्रों आदि को जल्दी आमंत्रित करना शुरू कर देता है।

- नहीं, एक अनुरोध-सीमक है जो आपको अक्सर सेवाओं तक पहुंचने की अनुमति नहीं देगा।

- आप डेटा संगति से कैसे निपटते हैं? मान लें कि हमारे पास दो उपयोगकर्ता हैं, हमें एक से कुछ लेने की जरूरत है, और दूसरे से कुछ चार्ज करना है, ताकि यह लेन-देन हो।

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

- यानी। क्या यह पहले से ही पता है कि गारंटी के लिए कैसे डेटा अखंडता में बनी रहेगी?

- हां।

Pixonic DevGAMM वार्ता के साथ अधिक वार्ता

• कंसूल का उपयोग राज्य स्तरीय सेवाओं (इवान बुबनोव, BIT.GAMES में DevOps) के लिए;
• CICD: डाउनटाइम (Egor Panov, Pixonic सिस्टम एडमिनिस्ट्रेटर) के बिना वितरित क्लस्टर सिस्टमों में निर्बाध तैनाती ;
• टैक्टिकूल मोबाइल ऑनलाइन शूटर मेटा सर्वर आर्किटेक्चर (पावेल प्लाटो, पैंजरडॉग में लीड सॉफ्टवेयर इंजीनियर);
• कैसे ECS, C # जॉब सिस्टम और SRP आर्किटेक्चर के लिए दृष्टिकोण को बदलते हैं (वैलेंटाइन साइमनोव, फील्ड इंजीनियर एट यूनिटी);
• के विकास में KISS सिद्धांत (Konstantin Gladyshev, लीड खेल 1C खेल स्टूडियो में प्रोग्रामर);
• क्लाइंट और सर्वर पर सामान्य गेम लॉजिक (एंटोन ग्रिगोरिव, पिक्सेल में उप तकनीकी अधिकारी)।
• क्लाउड में ककड़ी: उत्पाद तनाव परीक्षण के लिए बीडीडी लिपियों का उपयोग करना (एंटोन कोसयाकिन, एलिस प्लेटफॉर्म पर तकनीकी उत्पाद प्रबंधक)।