बैज के साथ स्टैक ओवरफ्लो जैसी साइटें कुछ प्रकार की देरी वाली नौकरी का उपयोग क्यों करती हैं यह निर्धारित करने के लिए कि नया बैज कब दिया जाए?

Question

स्टैक ओवरफ्लो में निफ्टी बैज सिस्टम है। एक बात मैंने देखी है कि बैज को तत्काल सम्मानित नहीं किया जाता है, लेकिन मानदंडों को पूरा करने के बाद कभी-कभी किसी प्रकार की देरी होती है। मैंने इसे अन्य साइटों पर देखा है जिनमें बैज भी हैं।

संभवतः ऐसा इसलिए है क्योंकि वे देरी वाली नौकरी का उपयोग कर रहे हैं जो समय-समय पर स्कैन करता है कि कोई नया बैज प्रदान करने की आवश्यकता है या नहीं। मैं इस दृष्टिकोण भी यहाँ की सलाह दी देखें:
How to implement badges?

हालांकि, मैं वास्तव में नहीं दिख रहा है यही कारण है कि यह आवश्यक होना चाहिए, और मेरी कार्यान्वयन में पक्ष रहा हूँ बस एक प्रणाली है जहाँ के बाद एक प्रासंगिक कार्रवाई किया जाता है के लिए उदाहरण के लिए, एक नई टिप्पणी पोस्ट की जाती है, एक चेकअवर्डबैज फ़ंक्शन कहा जाता है, जो जांचता है कि उपयोगकर्ता एक नई टिप्पणी बैज के मानदंडों को पूरा करता है या नहीं।

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

यह मुझे मारता है कि जिस प्रणाली का मैं पक्ष कर रहा हूं वह समझना तेज़ और बहुत आसान होना चाहिए। क्या डाउनसाइड्स मैं यहां लापता हूं, देरी वाली नौकरियों के साथ चीजों को जटिल करना क्यों जरूरी है?

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

Answer 1

आपका क्रियान्वयन (एक आप का वर्णन कर रहे हैं) की तरह सरल परिदृश्यों पर काम कर सकते हैं, लेकिन अगर चीजें अधिक जटिल हो जाता है आप एक समाधान है:

1. हर कार्रवाई में अनावश्यक चेकों बनाता
2. दंड प्रदर्शन जोड़ता है प्रत्येक कार्रवाई के लिए
4. स्केल नहीं करता है सभी नियमों के लिए केंद्रीय स्थान नहीं है।

Answer 2

ऐसा हो सकता है कि यदि कोई कार्रवाई की जाती है और तुरंत पूर्ववत हो जाती है, तो इसका परिणाम बैज से सम्मानित नहीं होगा।

Answer 3

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

आवधिक नौकरी सिर्फ नई स्थैतिक सामग्री उत्पन्न करेगी, और बहुत बार चलती है, लेकिन प्रत्येक पृष्ठ अनुरोध से कम बार-बार चलती है।

Answer 4

हालांकि यह केवल उस परिदृश्य के समानांतर है जो आप वर्णन कर रहे हैं, मुझे लगता है कि मेरे काम पर हम जो करते हैं उस पर चर्चा करने से इस दृष्टिकोण के तर्क के प्रकाश में मदद मिल सकती है।

मैं एक वास्तविक समय एल्गोरिदमिक ट्रेडिंग कंपनी के लिए काम करता हूं। हमारे सॉफ़्टवेयर द्वारा किए गए कार्यों का एक हिस्सा विक्रेता से प्रक्रिया बाजार डेटा है।

अब, ऐसी चीजें हैं जो प्रत्येक व्यक्तिगत बाजार टिक के जवाब में होने की आवश्यकता होती है। हम विश्लेषिकी चलाते हैं, सुरक्षा ट्रिगर्स हैं जो कुछ मामलों में प्रभाव डालते हैं आदि।लेकिन हम जो भी लागत से बचने से बचते हैं वह कोड को फूला रहा है जो इस "माध्यमिक" तर्क के साथ बाजार की घटनाओं पर प्रतिक्रिया करता है।

यहां तर्क यह है कि हमारा डेटा डेटा विक्रेता से नेटवर्क पर आता है, और हमें बिना किसी बैक-अप के इस डेटा फीड को स्वतंत्र रूप से बहने की आवश्यकता है। हमारा सॉफ्टवेयर प्रति सेकेंड लगभग 10,000 बाजार टिकों को संभाल सकता है। यदि उन बाजार की घटनाओं को संसाधित करने में बहुत लंबा समय लगता है, तो फ़ीड को पकड़ना शुरू हो जाता है और जितनी जल्दी हो सके बाजार में प्रतिक्रिया करने की हमारी क्षमता समझौता हो जाती है।

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

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

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