एक सामाजिक खेल में विलंबित टीम प्रसंस्करण

सभी को नमस्कार!

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

1. खिलाड़ी क्लाइंट पर कार्रवाई करता है
2. ग्राहक एक कार्रवाई की संभावना की जाँच करता है
3. सर्वर को एक कमांड भेजता है
4. सर्वर एक कार्रवाई की संभावना की जांच करता है, एक कमांड निष्पादित करता है, डेटाबेस में बदलाव करता है
5. क्लाइंट को सूचित किया जाता है कि सब कुछ ठीक है या त्रुटि के बारे में सूचित किया गया है

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

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

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



ऑपरेशन का सिद्धांत इस प्रकार है:

1. जब आप खेल शुरू करते हैं तो खिलाड़ी का पूरा खेल राज्य और वर्तमान खेल संतुलन प्राप्त करता है
2. खिलाड़ी क्लाइंट पर कार्रवाई करता है
3. क्लाइंट उन्हें मान्य करता है, लेकिन उन्हें सर्वर पर नहीं भेजता है, लेकिन जमा करता है
4. किसी भी हालत में पहुंचने पर, क्लाइंट इन सभी कमांड को एक बंडल में सर्वर को भेजता है
5. सर्वर पुष्टि करता है कि कमांड सही प्रारूप में हैं और बस क्लाइंट को बताता है कि सब कुछ ठीक है
6. सभी आदेश कतार में सहेजे गए हैं
7. सर्वर पर एक डेमॉन भी चल रहा है, जो समय-समय पर इस कतार से कमांड के पैक को खींचता है और उन्हें निष्पादित करता है

यह आदेशों के आस्थगित प्रसंस्करण के साथ एक योजना को चालू करता है, जिसमें निम्नलिखित फायदे हैं:

1. सर्वर अनुरोधों की संख्या बहुत कम हो गई है
2. आदेश को संसाधित करते समय mysql को कॉल की संख्या कम हो जाती है, क्योंकि डेटाबेस से बचत केवल पैक से सभी आदेशों को संसाधित करने के बाद होती है

बेशक, ऐसे नुकसान भी हैं जो हल किए जाने वाले कार्यों की अधिक संभावना है। और यहां आपको पहले से ही परियोजना की आवश्यकताओं को देखना होगा।
हमारी सूची इस प्रकार थी:

1. वर्तमान गेम स्थिति को उस समय प्राप्त करना जब इस उपयोगकर्ता के लिए पूरी कतार संसाधित नहीं हुई हो
2. कुछ आदेशों को वास्तविक समय में निष्पादन की आवश्यकता होती है (उदाहरण के लिए, वास्तविक खरीदना)
3. क्लाइंट पर खिलाड़ियों को धोखा देना (टीम क्लाइंट पर अमल करने में कामयाब रही, लेकिन सर्वर पर यह विफल रहा)
4. बहु-धागा प्रसंस्करण

प्रोजेक्ट गियरमैन कतार सर्वर का उपयोग करता है। अन्यथा, सब कुछ मानक है: php + mysql + memcached।
वर्तमान कार्यान्वयन में mysql और मेमकेच्ड (एक मेम्केच्ड सर्वर पर्याप्त नहीं है) के लिए पैनापन शामिल है।

आइए बात करते हैं कि उपरोक्त कार्यों को कैसे हल किया जाता है।

कमांड के पैक सर्वर पर चले गए। खिलाड़ी ने खेल बंद कर दिया और फिर शुरू हुआ। कतार अभी तक संसाधित नहीं हुई है।

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

वास्तविक समय में कुछ आदेशों को निष्पादित करना

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

ग्राहक को धोखा देने वाला खिलाड़ी। सर्वर और क्लाइंट पर तर्क में अंतर के कारण त्रुटियां

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

एकाधिक धागा प्रसंस्करण

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

यह वास्तव में वह सब है जो मैं बताना चाहता था। मैं कार्यान्वयन में देरी नहीं करना चाहता, क्योंकि वहां कुछ भी गैर-तुच्छ नहीं है।
फ्रेमवर्क Yii फ्रेमवर्क है। डेमॉन के लिए, यिक के लिए कमांड का उपयोग किया जाता है, जो निम्नानुसार शुरू होता है
nohup ./iyic que work> / dev / null &

टीम वंशजों की संख्या पर नज़र रखती है। अगर वे किसी कारण से गिरते हैं तो नए लॉन्च करते हैं।
वंशज गियरमैनवॉर्क को लाइन विश्लेषण के लिए पंजीकृत करते हैं।

आपका ध्यान के लिए धन्यवाद! अपने अंगूठे ऊपर रखो और साइन अप करें :)