बिगिनर से स्टाइल आइकन्स तक: हमने 2 जीआईएस में पुरस्कार कैसे बनाए

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

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

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

रैप्टर के साथ, हम आपको बताएंगे कि पुरस्कार प्रक्रिया के हुड के नीचे क्या है।

संकल्पना

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

सार के लिए आवश्यकताएँ

आवश्यकताएँ - एक उबाऊ बात है, इसलिए हम सभी बारीकियों को चित्रित नहीं करेंगे, हम सबसे महत्वपूर्ण चीजों पर ध्यान केंद्रित करेंगे:

• पुरस्कार केवल अधिकृत उपयोगकर्ताओं को जारी किए जाते हैं;
• इनाम पर प्रगति को अद्यतन करना जितना संभव हो उतना जल्दी होना चाहिए;
• इनाम - उत्पाद में कार्यों का एक सेट प्रदर्शन करने वाले उपयोगकर्ता का परिणाम: एक तस्वीर अपलोड करना, एक समीक्षा लिखना, दिशा-निर्देश ढूंढना, आदि बहुत सारे डेटा स्रोत हैं।

स्थापत्य विचार

कार्यान्वयन का विचार बहुत जटिल नहीं है। इसे सैद्धांतिक रूप से व्यक्त किया जा सकता है:

• पुरस्कार में कार्य शामिल होते हैं, जिसके परिणाम पुरस्कार को कॉन्फ़िगर करते समय निर्दिष्ट सूत्र के अनुसार जोड़ दिए जाते हैं;
• कार्य बाहर से आने वाली उपयोगकर्ता क्रियाओं के बारे में घटनाओं पर प्रतिक्रिया करता है, उन्हें फ़िल्टर करता है और काउंटरों के रूप में प्रगति में परिवर्तन को पंजीकृत करता है;
• "बाहरी ईवेंट" मास्टर सिस्टम (फोटो, फीडबैक, शोधन सेवाओं, आदि) या सहायक सेवाओं द्वारा उत्पन्न होते हैं जो पहले से मौजूद ईवेंट प्रवाह को परिवर्तित या फ़िल्टर करते हैं;
• घटना प्रसंस्करण अतुल्यकालिक रूप से होता है और यदि आवश्यक हो तो किसी भी समय रोका जा सकता है;
• उपयोगकर्ता अपने पुरस्कारों की वर्तमान स्थिति को देखता है;
• बाकी सब कुछ विवरण है ...

मुख्य संस्थाएँ

नीचे दिए गए आरेख विषय क्षेत्र की मुख्य संस्थाओं और उनके संबंधों को दर्शाता है:



आरेख में दो क्षेत्र प्रतिष्ठित हैं:

• योजना - पुरस्कारों की संरचना और उनके उच्चारण के नियमों का वर्णन करने के लिए एक क्षेत्र;
• डेटा - विशिष्ट उपयोगकर्ताओं के लिए अवार्ड क्षेत्र और उनकी वर्तमान स्थिति से संबंधित डेटा।

आरेख में निकाय:

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

सेवा संरचना

अब सेवा के मुख्य घटकों और उनकी निर्भरता पर विचार करें:

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

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

इवेंट हैंडलिंग

सामग्री

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

• फोटो - विभिन्न घटनाओं को उत्पन्न करता है जो तस्वीरों पर उपयोगकर्ताओं द्वारा किए गए संचालन से संबंधित हैं।
• समीक्षा - उपयोगकर्ता समीक्षाओं पर संचालन से संबंधित घटनाएं।
• डेटाफीडबैक - शोधन कार्यों से संबंधित घटनाएं। क्लेरिफिकेशन एक नक्शे पर किसी वस्तु के बारे में जानकारी में बदलाव है, चाहे वह कंपनी हो या स्मारक।
• चेक - 2GIS चेक एप्लिकेशन से संबंधित ईवेंट।
• BSS एनालिटिक्स इवेंट हैं जो 2GIS एप्लिकेशन उत्पन्न करते हैं। उदाहरण के लिए, एक निश्चित कंपनी का उद्घाटन, नाविक पर यात्राएं आदि।

मास्टर सिस्टम द्वारा उत्पन्न घटनाएं उनकी स्थिति को बदलने के क्रम में कफका विषय में आती हैं, जिससे उपयोगकर्ता के लिए पुरस्कार की प्रगति को न केवल आगे बढ़ाना संभव हो जाता है, बल्कि इसे वापस भी रोल किया जा सकता है। उदाहरण के लिए, यदि फोटो "सक्रिय" स्थिति में था, और फिर किसी कारण से "अवरुद्ध" की स्थिति हासिल कर ली, तो पुरस्कार पर प्रगति नीचे की ओर बदलनी चाहिए। पुरस्कार प्रगति आंतरिक वस्तुओं की व्याख्या है जिसे सामग्री काउंटर कहा जाता है।

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

• क्या पुरस्कार शुरू हो गया है?
• प्रगति क्या है
• क्या इनाम पूरी तरह से पूरा हो गया है?

फिल्टर और नियम

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

केवल उस सामग्री को छोड़ने के लिए जो पुरस्कार के लिए उपयुक्त है, हम प्रत्येक ईवेंट को फ़िल्टर और नियमों की एक श्रृंखला के माध्यम से चलाते हैं।

एक फ़िल्टर एक निश्चित प्रतिबंध है जो सामग्री पर लगाया जाता है। वह केवल इस सवाल का जवाब देने से संबंधित है: "क्या कोई नई घटना इस स्थिति में फिट होती है या नहीं?"
एक नियम एक विशेष फिल्टर है, जिसका उद्देश्य यह कहना है: "यदि कोई घटना शर्त पर फिट बैठती है, तो काउंटरों को कैसे बदलना चाहिए?" नियम में काउंटरों को बदलने के लिए एक एल्गोरिथ्म शामिल है। प्रत्येक पुरस्कार में केवल एक नियम होता है।

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

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

आवेदन की शुरुआत में, हम डेटाबेस से लोड किए गए फिल्टर के नाम से मेल खाते हैं और उन्हें एक विशिष्ट इनाम में डालते हैं। फ़िल्टर विवरण उदाहरण:

[ { "name":"SourceFilter", "config":{ "sources":["reviews"] } }, { "name": "ReviewsLengthFilter", "config": { "allowed_length": 100 } } ] 

इस मामले में, हम केवल उन समीक्षाओं को लेंगे (यह फ़िल्टर सरणी से पहला विवरण ऑब्जेक्ट द्वारा इंगित किया गया है), जिनमें से पाठ में 100 से अधिक अक्षर (सूची में दूसरा फ़िल्टर) शामिल हैं।

उदाहरण नियम का वर्णन:

 {"name": "ReviewUniqueByObjectRule","config":{}} 

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

बीएसएस

आइए हम बीएसएस घटनाओं की धारा के साथ काम करने पर अलग से ध्यान दें। इसके कम से कम तीन कारण हैं:

• विश्लेषिकी घटनाओं को वापस नहीं लाया जा सकता है, उनमें कोई स्थिति मॉडल नहीं है, जो सामान्य रूप से तार्किक है, क्योंकि नाविक के माध्यम से ड्राइविंग या मार्ग का निर्माण रद्द नहीं किया जा सकता है। कार्रवाई हुई या नहीं।
• वॉल्यूम। आपको याद दिला दूं कि 2GIS के कुल दर्शक प्रति माह 50+ मिलियन उपयोगकर्ता हैं। साथ में वे 1.5 बिलियन से अधिक खोज क्वेरी करते हैं, साथ ही कई अन्य क्रियाएं भी करते हैं: एप्लिकेशन लॉन्च करना, ऑब्जेक्ट का कार्ड देखना, आदि। चरम पर, घटनाओं की संख्या प्रति सेकंड 50,000 तक पहुंच सकती है। उपयोगकर्ता को इनाम देने के लिए हमें फ़िल्टर के माध्यम से यह सारी जानकारी पास करनी चाहिए।
• विश्लेषिकी घटनाओं में विशेषताएं हैं: कई प्रारूप, प्रकार की एक विस्तृत विविधता।

इस सभी ने बीएसएस विषय से डेटा के प्रसंस्करण को बहुत प्रभावित किया, क्योंकि अगर हमें वास्तविक समय की आवश्यकता है, तो हमें बहुत करीब प्रसंस्करण समय की आवश्यकता है।

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

पुरस्कार जारी करना

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

पहला सवाल जो उठता है वह यह है कि एक अलग कर्मचारी को आउटपुट क्यों आवंटित किया जाता है, क्या इसे प्रत्येक घटना को संसाधित करते समय नहीं निकाला जा सकता? उत्तर: संभव है, लेकिन इसके लायक नहीं है।

एक अलग प्रक्रिया के लिए प्रत्यर्पण आवंटित करने के कई कारण हैं:

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

एक अलग एच्सीवॉर्कर (पुरस्कार जारी करने के लिए हैंडलर) के उभरने के कारणों को सुलझा लिया गया। अब आपको प्रसंस्करण के दो महत्वपूर्ण भागों से निपटने की आवश्यकता है:

1. इनाम में क्वास का एक सेट है। इन कार्यों के लिए काउंटरों का एक सेट है। कैसे समझें कि पुरस्कार कितना है और इसे कोड में कैसे व्यक्त किया जाए?
   उदाहरण: आपको 3 समीक्षा लिखने या 3 फ़ोटो अपलोड करने की आवश्यकता है। उपयोगकर्ता के पास 1 समीक्षा और 2 तस्वीरें हैं। पुरस्कार की प्रगति क्या है? उत्तर: 3, क्योंकि उपयोगकर्ता निश्चित रूप से सुनिश्चित करेगा कि आपको कुल 3 की आवश्यकता है।
2. हमारे पास पुरस्कार जारी करने के लिए एक अलग हैंडलर है। हर बार, प्रत्येक अधिकृत उपयोगकर्ता के लिए कई दर्जन पुरस्कार, यानी कई दसियों लाख, जल्दी से सफल होने की संभावना नहीं है। अंतिम प्रसंस्करण के बाद से वह उन विशेष उपयोगकर्ताओं की प्रगति के बारे में कैसे जान सकता है और किन कार्यों में बदलाव आया है?

हम प्रत्येक भाग पर अलग से विचार करेंगे।

प्रगति का प्रवाह

पुरस्कारों द्वारा कार्यों की प्रगति को प्रगति में कैसे बदलना है, इसकी बेहतर समझ के लिए, हम पुरस्कारों को श्रेणियों में विभाजित करते हैं और परिवर्तनों को देखते हैं।

"प्रति एक्स इकाइयों में एक कार्य पूरा करें।" उदाहरण: नाविक पर 10 किमी।



"प्रत्येक एक्स इकाइयों के लिए कई कार्य पूरे करें।" उदाहरण: 5 फ़ोटो अपलोड करें और कार्ड में 5 समीक्षाएं लिखें - केवल 10 इकाइयों की सामग्री।



"एक्स इकाइयों के लिए कुल कई कार्यों को पूरा करें।" उदाहरण: 5 समीक्षा लिखें या 5 तस्वीरें अपलोड करें।



"प्रकार द्वारा समूहीकृत कई कार्य।" उदाहरण: सामग्री की 5 इकाइयों (फोटो या समीक्षा) को अपलोड करें और नाविक पर 10 किमी ड्राइव करें।



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

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

रणनीति एक पेड़ के रूप में प्रस्तुत की जाती है, जहां प्रत्येक नोड:

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

उपरोक्त उदाहरणों का वर्णन करने के लिए, एक ऑपरेशन पर्याप्त है - राशि। Sum एक नंबर के साथ उपयोगकर्ता की प्रगति को स्पष्ट रूप से दिखाने के लिए बहुत अच्छा है, लेकिन यदि वांछित है तो अन्य संचालन का उपयोग किया जा सकता है।

यहाँ अंतिम श्रेणी के लिए एक उदाहरण रणनीति विवरण दिया गया है:

 { "goal": 15, "operation": "sum", "strategy": [ { "goal": 5, "operation": "sum", "strategy": [ { "objective_id": "photo" }, { "objective_id": "reviews" } ] }, { "goal": 10, "operation": "sum", "strategy": [ { "objective_id": "navi", "normalization_factor": 0.001 } ] } ] } 

आवश्यक अद्यतन

कई हैंडलर हैं जो लगातार उपयोगकर्ताओं द्वारा घटनाओं का विश्लेषण करते हैं और कार्यों की प्रगति में परिवर्तन लागू करते हैं। प्रत्येक पुरस्कार के साथ सभी उपयोगकर्ताओं की एक नियमित खोज से कई दसियों लाख पुरस्कारों का विश्लेषण होगा - बहुत उत्साहजनक नहीं, बशर्ते कि वास्तविक अपडेट हजारों में मापा जाएगा। केवल हजारों के बारे में कैसे सीखें और लाखों सीपीयू बर्बाद न करें?

केवल उन पुरस्कारों पर प्रगति को कैसे पुनर्गठित किया जाए, इसका विचार वास्तव में बदल गया है, बहुत जल्दी आ गया। यह वेक्टर घड़ियों के उपयोग पर आधारित है।

विवरण से पहले मैं संस्थाओं की याद दिलाऊंगा:

• UserObjective - पुरस्कार निर्धारित करके उपयोगकर्ता की प्रगति का डेटा।
• UserAchieve - इनाम उपयोगकर्ता प्रगति डेटा।

कार्यान्वयन इस तरह दिखता है:

• हमें PostgreSQL में UserObjective और UserAchieve और Sequence के लिए संस्करण क्षेत्र मिलता है।
• UserObjective निकाय का प्रत्येक अद्यतन अपना संस्करण बदलता है। मान अनुक्रम से लिया गया है (हमारे पास यह सभी रिकॉर्ड के लिए सामान्य है)।
• UserAchieve का संस्करण मान संबद्ध UserObjective के संस्करणों के अधिकतम के रूप में निर्धारित किया जाएगा।
• प्रत्येक प्रसंस्करण चक्र पर, AchievesWorker ऐसे UserObjective की खोज करता है जिसके लिए कोई UserAchieve या UserAchieve.version <UserObjective.version नहीं है। समस्या को डेटाबेस के लिए एकल क्वेरी द्वारा हल किया जाता है।

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

निष्कर्ष

इस तथ्य के बावजूद कि लेख काफी हद तक सही निकला, पर्दे के पीछे बहुत सारी बारीकियां बनी रहीं, क्योंकि उनके बारे में संक्षेप में बात करना संभव नहीं होगा।

हमने पुरस्कारों के लिए क्या निष्कर्ष निकाला है:

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