मेरे मूल प्रतिक्रिया से आगे बढ़ते हुए , यह फिर से कुछ ऐसा है जहाँ कुछ अलग सोच आपकी सहायता के लिए आ सकती है। और इस तरह यह वास्तुकला के बारे में यह कहने से कहीं अधिक प्रतीत होता है कि आपके कोड को "एक निश्चित तरीके से" लागू करना सबसे अच्छा तरीका होगा।
उस पर आपकी टिप्पणी और यहां आपके प्रश्न से, ऐसा लगता है कि जिस समस्या को आपको हल करने की आवश्यकता है वह यह है कि अन्य के लिए सैनिकों की संख्या को कैसे समायोजित किया जाए। उपयोगकर्ता चाल खेल रहा है। आइए फिर से उसी डेटा को देखकर शुरू करें:
{ "_id" : ObjectId("531cf5f3ba53b9dd07756bb7"), "user" : "A", "units" : 50 }
{ "_id" : ObjectId("531cf622ba53b9dd07756bb9"), "user" : "B", "units" : 62 }
"चाल" करना
तो यहाँ स्थिति यह है कि उपयोगकर्ता "B" ने अभी-अभी अपनी चाल चली है और प्रतिबद्ध 62 . है उस चाल में इकाइयाँ। पिछली पोस्ट में मैंने समझाया था कि मिलान करने वाले उपयोगकर्ता "ए" के लिए कदम कैसे वापस लाया जाए, और इसलिए आप उन्हें "जोड़ी" कर सकते हैं और जीत निर्धारित कर सकते हैं।
इसे और आगे ले जाते हुए, विचार करें कि अनुरोध में क्या हुआ। उपयोगकर्ता "बी" सबमिट किया गया, फिर आप उनके कदम के लिए दस्तावेज़ सम्मिलित करते हैं, फिर आप मिलान वाले को वापस पढ़ते हैं। तो अभी आपके पास अनुरोध के लिए स्मृति में दोनों दस्तावेज़ हैं। यदि आप सत्र डेटा पर विचार करते हैं, तो आपके पास कुछ ऐसा हो सकता है (संक्षेप में):
{
currentUnits: 100
}
आइए इसे शुरुआती गिनती कहते हैं। इसलिए जब आप सबमिट करें उपयोगकर्ता की ओर से एक चाल, आप बस उनके पास मौजूद सैनिकों की संख्या घटाते हैं। तो सम्मिलित करें . करते समय का 62 सैनिकों, काउंटर इस पर जाता है:
{
currentUnits: 38
}
यह अच्छा अभ्यास है, जैसा कि आप इस कदम के भीतर सम्मिलित पावती पर करते हैं। लेकिन उस कॉलबैक के अंदर आप मेरे कहे अनुसार खोज करने जा रहे हैं, और वह केवल एक दस्तावेज़ लौटाता है। अब आपके पास वह जानकारी है जिसकी आप तुलना कर सकते हैं और अपना गणित कर सकते हैं। उपयोगकर्ता "बी" जीतता है ताकि आप अपना सत्र मान समायोजित कर सकें:
{
currentUnits: 150
}
ताकि उपयोगकर्ता "बी" के लिए कदम के लिए सबकुछ शामिल हो। जब एक चाल चल रही थी तो आपने इकाइयाँ निकाल लीं, आपने दूसरे खिलाड़ी का मिलान किया, फिर आपने "गणित किया" और अपने परिणामों को समायोजित किया। पूर्ण! ओह, और आपने सहेजें एक सतत स्टोर में सभी सत्र डेटा आपने नहीं किया? हाँ हाँ। और यह भी कि सत्र डेटा को संशोधित करने के लिए एक्सेस प्राप्त करने के लिए उपयोगकर्ता हैंडल (या उपयोगकर्ता वास्तव में सत्र आईडी है) से जुड़ा हुआ है।
जो कुछ बचा है वह दूसरे खिलाड़ी को "सूचित" करना है।
किसी और को खबर बताना
यह भाग सरल होना चाहिए। इसलिए मैं इसे आपके लिए कोडिंग नहीं कर रहा हूं। आप socket.io का उपयोग कर रहे हैं आपके आवेदन के लिए, तो यह सब नीचे आता है एक संदेश भेज रहा है। इसका मतलब है कि आपके द्वारा "उत्सर्जित" डेटा क्लाइंट पर अन्य उपयोगकर्ता को बताता है कि उन्होंने "अपने सैनिकों को खो दिया", हालांकि आप इससे निपटना चाहते हैं। लेकिन यह भी याद रखें कि उनकी चाल . के दौरान आपने उन इकाइयों को "हटा" दिया था सबमिट किया गया था। उन सभी मामलों में जो यह सुनिश्चित कर रहे हैं कि कोई भी उनसे अधिक प्रतिबद्ध नहीं हो सकता है।
यहां बात करने की एकमात्र संभावित चीज है स्केलिंग एक उदाहरण से परे आपका आवेदन। तो आप एक सर्वर इंस्टेंस पर काम कर रहे "नोड" पर सभी घटनाओं के साथ खुशी से बात कर सकते हैं, लेकिन "स्केल" करने के लिए आपको विभिन्न उदाहरणों के बीच संदेश पास करने की आवश्यकता होगी।
MongoDB का उपयोग करके इसे संभालने का एक तरीका कैप्ड संग्रह हो सकता है। ।
कैप्ड संग्रह आम तौर पर सेट . रखने के तरीके के अलावा क्या करते हैं दस्तावेज़ों के संग्रह के लिए आकार, एक और चीज़ है जो वे ऑफ़र करते हैं, और वह है एक टेलेबल कर्सर . नोड ड्राइवर के साथ एक बनाने का एक बहुत ही असामान्य तरीका इस प्रकार होगा:
var options = { tailable: true, awaitdata: true, numberOfRetries: -1 };
var cursor = collection.find(query, options).sort({ $natural: 1 });
पूर्ण विकल्प Cursor() ड्राइवर मैनुअल पेज का सेक्शन। आप इन "देशी" तरीकों को नेवला में विशिष्ट तरीके से प्राप्त कर सकते हैं।
संग्रह में "अंतिम सम्मिलित" दस्तावेज़ को "अनुसरण" करने के लिए "टेलेबल" कर्सर क्या सेट किया गया है और आप इस तरह से एक सम पोल के साथ बैठ सकते हैं और "फॉलो" कर सकते हैं, जैसे:
(function more() {
cursor.nextObject(handle(function(doc) {
if (!doc) return setTimeout(poll, self.wait);
callback(doc);
latest = doc._id;
more();
}));
})();
तो इस तरह के एक निर्माण के भीतर आप नए डाले गए दस्तावेज़ को "ढूंढते हैं" और संसाधित होने वाली जानकारी को अपने आंतरिक कॉलबैक में पास करते हैं, जहां आप ग्राहकों को संदेश "भेजते हैं", चीजों को अपडेट करते हैं और जो कुछ भी आप करना चाहते हैं।
आपके पास वास्तविक "अनुरोध" पर वापस, फिर आप अलग "कैप्ड संग्रह" में "अपना गणित" करने के बाद एक सम्मिलित जारी करेंगे। आप संक्षेप में कुछ अर्थपूर्ण चाहते हैं जैसे:
{ "player": "B", "vsplayer": "A", "win": 50, "loss": 62 }
और फिर ये बस हैं सम्मिलित करता है। तो आप एक TTL अनुक्रमणिका सेट अप करेंगे समय के साथ विलोपन को संभालने और कैप किए जाने के लिए, पुरानी प्रविष्टियाँ स्वाभाविक रूप से संग्रह में मौजूद प्रविष्टियों को "बाहर धकेल" कर हटा देंगी।
आपके "क्लाइंट" पक्ष पर, प्रत्येक जुड़ा हुआ उपयोगकर्ता एप्लिकेशन "अंतिम _id" मान का ट्रैक रखता है। तो नई सम्मिलित प्रविष्टियाँ हमेशा हैं "पुराने" पिछले वाले के मूल्य में अधिक।
तो एक सतत कतार बनाने के लिए मोंगोडीबी का उपयोग करने का "एक तरीका" है जिसे आप एकाधिक एप्लिकेशन सर्वर उदाहरणों के बीच संदेश साझा करने के लिए अनुक्रमिक रूप से संसाधित कर सकते हैं।
अंतिम शब्द
इस तरह से "टेल-एबल" कर्सर को लागू करने के लिए कहा गया है, मेरे पैसे के लिए मैं zeromq का उपयोग करूंगा। या बहुत कुछ पसंद है। लेकिन यदि आप किसी अन्य तकनीक में तल्लीन नहीं करना चाहते हैं तो आपको मोंगोडीबी विधि आपके लिए अधिक उपयुक्त लग सकती है। या शायद आपके आवेदन (कम से कम इस स्तर पर) द्वारा इस तरह की "स्केलेबिलिटी" की आवश्यकता नहीं है और अनुरोध के भीतर "सॉकेट.आईओ" विधियों को पास करना पर्याप्त होगा। आप पर निर्भर है।
काफी हद तक, आप अभी भी "पारिंग" और "डिलीटिंग" की अपनी अवधारणाओं पर "लटका हुआ" प्रतीत होते हैं। यह अंतिम प्रतिक्रिया में शामिल करने का इरादा था और यह कहना था कि हटाना संसाधित होने पर दस्तावेज़ों की संख्या आवश्यक नहीं . है . वर्णित प्रक्रिया सुनिश्चित करती है कि आपको "समान जोड़ी" . कभी नहीं मिलती किसी भी अनुरोध पर वापस।
मैं आपको "फिर से पढ़ने" . के लिए प्रोत्साहित करूंगा वह जानकारी और वास्तव में प्रक्रिया को समझते हैं। और पूछें कि क्या आपके कोई प्रश्न हैं। वहां जो चर्चा की गई है, उससे आप डेटा एक्सेस पैटर्न की सादृश्यता "मिलान करने वाले जोड़े" की तुलना में "एक स्टैक से खेलना" की तरह है।
तो जवाब में आपको क्या दिया गया था, निम्नलिखित यहां वर्णित तर्क के साथ सब . है अपने डेटा एक्सेस पैटर्न को सेट करने के लिए आपको इसकी आवश्यकता होनी चाहिए। आपका अन्य घटक निश्चित रूप से मैसेजिंग होगा, लेकिन यह आपको उस डेटा तक पहुंच प्रदान करता है जिसकी आपको आवश्यकता है।
