How a team of just two engineers tackled real-time persisted events for hundreds of millions of players केवल दो इंजीनियरों के साथ, सुपरसेल ने अपने बुनियादी खाता प्रणाली को सैकड़ों मिलियन गेमर्स को जोड़ने वाले एक सोशल प्लेटफॉर्म में विकसित करने का डरावना कार्य किया. खाता प्रबंधन, दोस्त अनुरोध, क्रॉस गेम प्रोमोशन, चैट, खिलाड़ियों की उपस्थिति ट्रैकिंग, और टीम गठन - यह सब उनके पांच प्रमुख गेमों के माध्यम से काम करना था. और वे चाहते थे कि यह सब एक एकल समाधान द्वारा कवर किया जाए जो एक एकल इंजीनियर को बनाए रखने के लिए पर्याप्त सरल था, लेकिन वास्तविक समय में बड़े पैमाने पर मांग को संभालने के लिए पर्याप्त शक्तिशाली था. Supercell के सर्वर इंजीनियर, एडवर्ड Fagerholm ने हाल ही में साझा किया कि उनकी शक्तिशाली दो टीम ने इस कार्य को कैसे संबोधित किया. यह जानने के लिए पढ़ें कि कैसे उन्होंने एक सरल खाता प्रबंधन उपकरण को एक व्यापक पार गेम सोशल नेटवर्क बुनियादी ढांचे में परिवर्तित किया जिसने ऑपरेटिंग सरलता और उच्च प्रदर्शन दोनों को प्राथमिकता दी। नोट: यदि आप इस तरह के इंजीनियरिंग प्रदर्शनों के बारे में सुनना पसंद करते हैं, तो हमें Monster Scale Summit (मुक्त + आभासी) में शामिल करें। एस। नोट : यदि आप इस तरह के इंजीनियरिंग प्रदर्शनों के बारे में सुनना पसंद करते हैं, तो हमारे साथ जुड़ें Monster Scale के बारे में राय (मुक्त + आभासी)। डिज्नी + / हूलू, स्लाक, कैनवा, Uber, Salesforce, Atlassian और अधिक से इंजीनियर रणनीतियों और मामले का अध्ययन साझा करेंगे नोट Monster Scale के बारे में राय पृष्ठभूमि: Supercell कौन है? सुपरसेल हाई डे, क्लैश ऑफ़ क्लैन्स, बुम बेज़, क्लैश रॉयल और ब्रोल स्टार के हिट गेम्स के पीछे फिनलैंड में स्थित कंपनी है. इन गेमों में से प्रत्येक ने जीवनकाल में $ 1 बिलियन की आय उत्पन्न की है। किसी तरह वे सुपर छोटे कर्मचारियों के साथ ऐसा करने में कामयाब रहे। बहुत हाल तक, सैकड़ों मिलियन मासिक सक्रिय उपयोगकर्ताओं की सेवा करने वाले गेमों के लिए सभी खाता प्रबंधन कार्यक्षमता को केवल दो इंजीनियरों द्वारा बनाया और प्रबंधित किया गया था। Supercell ID के बारे में राय सुपरसेल आईडी एक बुनियादी खाता प्रणाली के रूप में पैदा हुआ था - उपयोगकर्ताओं को खातों को पुनर्प्राप्त करने और उन्हें नए उपकरणों पर स्थानांतरित करने में मदद करने के लिए। एडवर्ड ने समझाया, "क्लाइंट खाते एपीआई पर एचटीटीपी पूछताछ चला सकता है, जो मुख्य रूप से हस्ताक्षरित टोकन वापस करता है जिसे क्लाइंट अपनी पहचान साबित करने के लिए गेम सर्वर को प्रस्तुत कर सकता है। कुछ ऑपरेशन, जैसे कि दोस्त अनुरोध करने के लिए, खाते एपीआई को किसी अन्य खिलाड़ी को एक सूचना भेजने की आवश्यकता थी. उदाहरण के लिए, 'क्या आप इस दोस्त अनुरोध को मंजूरी देते हैं? दो रास्ते में संचार 2020 के अंत में सुपरसेल आईडी परियोजना में शामिल होने के बाद, एडवर्ड ने सूचना बैकेंड पर काम करना शुरू कर दिया - मुख्य रूप से अपने पांच गेमों में क्रॉस-प्रोमोशन के लिए। ग्राहकों को प्रॉक्सी सर्वरों के एक फ्लोट से कनेक्ट किया गया था, फिर एक राउटिंग तंत्र ने घटनाओं को सीधे ग्राहकों को धक्का दिया (यह खेल के माध्यम से जाने के बिना) यह क्रॉस-प्रोमोशन और दोस्त अनुरोधों को संभालने के तत्काल लक्ष्य के लिए पर्याप्त था। उन्होंने महसूस किया कि वे सुपरसेल आईडी सिस्टम के दायरे को काफी बढ़ाने के लिए दो दिशा संचार का उपयोग कर सकते हैं. एडवर्ड ने समझाया, "आमतौर पर, यह हमें उन सुविधाओं को लागू करने की अनुमति देता है जो पहले गेम सर्वर का हिस्सा थे. हमारा लक्ष्य उन सुविधाओं को लेना था जिन्हें किसी भी नए गेम के विकास में आवश्यकता हो सकती है और उन्हें हमारे सिस्टम में पैक करें - इस प्रकार उनके विकास को तेज करें। इसके साथ, सुपरसेल आईडी ने एक क्रॉस गेम सोशल नेटवर्क में बदलना शुरू कर दिया जो दोस्त ग्राफ, टीम बनाने, चैट और दोस्त राज्य ट्रैकिंग जैसे सुविधाओं का समर्थन करता था। सुपरसेल आईडी को क्रॉस गेम सोशल नेटवर्क में विकसित करना इस बिंदु पर, बैकेंड के सामाजिक नेटवर्क पक्ष अभी भी एक एकल व्यक्ति परियोजना थी, इसलिए उन्होंने इसे सरलता के साथ डिजाइन किया। सही Abstraction खोजें "हम केवल एक सरल अवलोकन चाहते थे जो हमारे सभी उपयोगों का समर्थन करेगा और इसलिए एक ही इंजीनियर द्वारा डिजाइन और लागू किया जा सकता था," एडवर्ड ने समझाया। सही अवलोकन खोजने में कुंजी थी. और Change Data Capture के साथ एक रीरेखिक कुंजी-मूल्य स्टोर बिल पूरी तरह से बिल में फिट था. यहां वे इसे कैसे लागू करते हैं: कुंजी मूल्य स्टोर में शीर्ष स्तर की कुंजी वे विषय हैं जिन्हें सदस्यता दी जा सकती है। प्रत्येक शीर्ष स्तर की कुंजी के तहत दो परतों का एक नक्शा है – नक्शा (सेंटर, नक्शा (सेंटर, string))। सबसे आंतरिक नक्शे में मूल्य भी टाइमस्टैम्प किए जाते हैं। प्रत्येक डेटा स्रोत अपने स्वयं के टाइमस्टैम्प को नियंत्रित करता है और सही क्रम को परिभाषित करता है। नक्शा (String, String) डेटा में एक विशिष्ट परिवर्तन "स्तरीय बराबर 10" में परिवर्तन होगा "स्तरीय बराबर 11" के रूप में। सही डेटाबेस खोजें उन्हें एक डेटाबेस की आवश्यकता थी जो उनकी तकनीकी आवश्यकताओं का समर्थन करेगी और उनकी न्यूनतम टीम को देखते हुए प्रबंधित किया जा सकता है। कम लाटेंसी के साथ कई छोटे लेखन को संभालता है एक Hierarchical Data Model का समर्थन करता है एक सेवा के रूप में बैकअप और क्लस्टर ऑपरेशन प्रबंधित करता है ScyllaDB क्लाउड एक शानदार फिट साबित हुआ. (ScyllaDB क्लाउड ScyllaDB की पूरी तरह से प्रबंधित संस्करण है, एक डेटाबेस जिसे बड़े पैमाने पर अनुमानित कम लाटेंस प्रदान करने के लिए जाना जाता है)। यह सब कैसे खेलता है इस बारे में एक विचार के लिए कि सुपरसेल गेम में यह कैसे खेला जाता है, आइए दो उदाहरणों को देखते हैं। सबसे पहले, चैट संदेशों पर विचार करें. एक सरल चैट संदेश उनके डेटा मॉडल में निम्नलिखित रूप से प्रतिनिधित्व किया जा सकता है: एडवर्ड ने समझाया, "उत्तर-स्तरीय कुंजी जिसे साइन अप किया जाता है वह चैट रूम आईडी है. अगले स्तर की कुंजी एक टाइमस्टैम्प-यूआईडी है, इसलिए हमारे पास प्रत्येक संदेश का एक क्रमशः है और चैट इतिहास पूछ सकता है. आंतरिक नक्शा में वास्तविक संदेश और इसके साथ जुड़े अन्य डेटा शामिल हैं। एडवर्ड के अनुसार, "जब आप लड़ाई के लिए एकीकृत होते हैं, तो आप वास्तविक समय में अपने दोस्तों के एवाटार और वर्तमान निर्माण को देखना चाहते हैं - मूल रूप से आपके दोस्तों के हथियार और उपकरण, साथ ही साथ वे क्या कर रहे हैं। Players’ state data is encoded into Supercell’s hierarchical map as follows: Note that: शीर्ष स्तर खिलाड़ी आईडी है, दूसरा स्तर प्रकार है, और आंतरिक नक्शा में डेटा होता है। सुपरसेल आईडी को डेटा को समझने की आवश्यकता नहीं है; यह केवल इसे गेम क्लाइंट को आगे बढ़ाता है। गेम क्लाइंट को दोस्त ग्राफ को जानने की आवश्यकता नहीं है क्योंकि राउटिंग सुपरसेल आईडी द्वारा संसाधित होती है। सिस्टम वास्तुकला में गहराई से आइए एडवर्ड द्वारा प्रदान की गई सिस्टम वास्तुकला की एक यात्रा के साथ समाप्त करते हैं। "बैकेंड एपीआई, प्रॉक्सी, और घटना मार्गदर्शन / स्टोरेज सर्वर में विभाजित है। विषय घटना मार्गदर्शन सर्वर पर रहते हैं और उन पर विभाजित होते हैं। एक क्लाइंट एक प्रॉक्सी से जुड़ता है, जो क्लाइंट के विषय सदस्यता को संभालता है। प्रत्येक विषय में एक प्राथमिक और बैकअप शेड होता है. यदि प्राथमिक नीचे जाता है, तो प्राथमिक शेड हर संदेश के लिए खोए गए संदेशों का पता लगाने के लिए स्मृति अनुक्रम संख्याओं को बनाए रखता है. माध्यमिक अनुक्रम संख्याओं के बिना संदेशों को प्रसारित करेगा. यदि प्राथमिक नीचे है, तो प्राथमिक आ रहा है, तो क्लाइंट पर स्थिति की नवीनीकरण को सक्रिय करेगा, साथ ही अनुक्रम संख्याओं को रीसेट करेगा. राउटिंग परतों के लिए एपीआई एक सरल पोस्ट-वेवेंट आरपीसी है जिसमें विषय, प्रकार, कुंजी, मूल्य tuples का एक बैच होता है। प्रत्येक एपीआई का काम केवल उपरोक्त tuple प्रतिनिधित्व में अपने डेटा को फिर से लिखना है। ग्राहकों को प्रसारित करने से पहले प्रत्येक घटना ScyllaDB में लिखी जाती है। हमारे एपीआई सिंक्रनाइज़ होते हैं इस अर्थ में कि यदि एक एपीआई कॉल एक सफल जवाब देता है, तो संदेश ScyllaDB में निरंतर था. एक ही घटना को कई बार भेजना कोई नुकसान नहीं करता है क्योंकि क्लाइंट पर अपडेट लागू करना एक idempotent ऑपरेशन है, संभवतः एक ही संदेश के लिए कई अनुक्रम संख्याओं को मैप करने के अलावा। जब आप कनेक्ट करते हैं, तो प्रॉक्सी आपके सभी दोस्तों को पता लगाएगा और उनके विषयों के लिए साइन अप करेगा, जिस समूह के लिए आप शामिल हैं. हम कनेक्ट करने वाले क्लाइंट के लिए विषयों के लिए भी साइन अप करते हैं. इनका उपयोग क्लाइंट को सूचनाएं भेजने के लिए किया जाता है, जैसे दोस्त अनुरोध और क्रॉस प्रोमोशन। एक राउटर रिबूट प्रॉक्सी से विषयों के लिए एक पुनः सदस्यता को सक्रिय करता है। हम प्रोटोकॉल बफर का उपयोग बैंडविड्थ लागत को बचाने के लिए करते हैं. सभी लोड संतुलन TCP स्तर पर होता है ताकि यह सुनिश्चित किया जा सके कि एक ही HTTP/2 कनेक्शन के माध्यम से अनुरोधों को प्रॉक्सी पर एक ही TCP सॉकेट द्वारा संसाधित किया जाता है. यह हमें प्रारंभिक सुनने पर स्मृति में कुछ जानकारी की कैश करने की अनुमति देता है, इसलिए हमें अन्य अनुरोधों पर पुनरावृत्ति करने की आवश्यकता नहीं है. हमारे पास पर्याप्त समकक्ष क्लाइंट हैं कि हमें अलग-अलग लोड संतुलन HTTP/2 अनुरोधों को अलग-अलग करने की आवश्यकता नहीं है, क्योंकि ट्रैफ़िक वैसे भी समान रूप से वितरित होता है, और अनुरोधों को विभिन्न उपयोगकर्ताओं के बीच संसाधित लेकिन यह खेल खत्म नहीं है यदि आप पूरी तकनीकी बातचीत देखना चाहते हैं, तो बस नीचे प्ले पर दबाएं: और यदि आप गेमिंग दुनिया में ScyllaDB की भूमिका के बारे में अधिक पढ़ना चाहते हैं, तो आप यह भी पढ़ना चाहते हैं: एपिक गेम्स: कैसे एपिक गेम्स NVMe और S3 के सामने एक बाइनरी कैश के रूप में ScyllaDB का उपयोग करता है Unreal Cloud DDC द्वारा उपयोग किए जाने वाले बड़े गेम संपत्तियों के वैश्विक वितरण को तेज करने के लिए। Tencent Games: कैसे Tencent Games ने Pulsar और ScyllaDB के साथ CQRS और घटना स्रोत पैटर्न पर आधारित सेवा आर्किटेक्चर का निर्माण किया। Discord: कैसे Discord ScyllaDB का उपयोग अपने बड़े पैमाने पर विकास को प्रोत्साहित करने के लिए करता है, एक निशान गेमिंग प्लेटफॉर्म से दुनिया के सबसे बड़े संचार प्लेटफॉर्म में से एक में चले जाते हैं। Epic Games के बारे में: Tencent खेल: विरोधाभास :
