डॉनी का जवाब (मतदान) शायद आपका सबसे अच्छा विकल्प है - सरल और काम करता है। यह लगभग हर मामले को कवर करेगा (इसकी संभावना नहीं है कि एक साधारण पीके लुकअप एक बहुत लोकप्रिय साइट पर भी प्रदर्शन को नुकसान पहुंचाएगा)।
पूर्णता के लिए, और यदि आप मतदान से बचना चाहते हैं, तो आप पुश-मॉडल . विकिपीडिया लेख में वर्णित विभिन्न तरीके हैं। यदि आप राइट-थ्रू कैश बनाए रख सकते हैं (हर बार जब आप रिकॉर्ड अपडेट करते हैं, तो आप कैश अपडेट करते हैं), तो आप डेटाबेस लोड को लगभग पूरी तरह से समाप्त कर सकते हैं।
हालांकि, टाइमस्टैम्प "last_updated" कॉलम का उपयोग न करें। उसी सेकंड के भीतर के संपादन अनसुने नहीं हैं। यदि आप यह सुनिश्चित करने के लिए अतिरिक्त जानकारी (अपडेट करने वाला सर्वर, रिमोट एड्रेस, पोर्ट, आदि) जोड़ते हैं, तो आप इससे दूर हो सकते हैं, यदि एक ही सर्वर पर एक ही सेकंड में दो अनुरोध आए, तो आप अंतर का पता लगा सकते हैं। यदि आपको उस सटीकता की आवश्यकता है, हालांकि, आप एक अद्वितीय संशोधन फ़ील्ड का भी उपयोग कर सकते हैं (यह आवश्यक रूप से एक वृद्धिशील पूर्णांक नहीं है, केवल उस रिकॉर्ड के जीवनकाल के भीतर अद्वितीय है)।
किसी ने लगातार कनेक्शन का उल्लेख किया है - इससे मतदान प्रश्नों की सेटअप लागत कम हो जाएगी (प्रत्येक कनेक्शन स्वाभाविक रूप से डेटाबेस और होस्ट मशीन पर संसाधनों का उपभोग करता है)। आप एक ही कनेक्शन (या यथासंभव कम) को हर समय (या यथासंभव लंबे समय तक) खुला रखेंगे और उसका उपयोग करेंगे (यदि वांछित हो तो कैशिंग और संस्मरण के संयोजन में)।
अंत में, SQL कथन हैं जो आपको UPDATE या INSERT पर एक शर्त जोड़ने की अनुमति देते हैं। मेरा एसक्यूएल वास्तव में जंग खा रहा है, लेकिन मुझे लगता है कि यह कुछ ऐसा है UPDATE ... WHERE ... . सुरक्षा के इस स्तर से मेल खाने के लिए, आपको अपडेट भेजने से पहले अपनी खुद की पंक्ति लॉकिंग करनी होगी (और सभी त्रुटि प्रबंधन और सफाई जो आवश्यक हो सकती है)। इसकी संभावना नहीं है कि आपको इसकी आवश्यकता होगी; मैं इसका उल्लेख केवल पूर्णता के लिए कर रहा हूँ।
संपादित करें:
आपका समाधान ठीक लगता है (कैश टाइमस्टैम्प, किसी अन्य सर्वर पर प्रॉक्सी मतदान अनुरोध)। केवल एक ही परिवर्तन जो मैं करूंगा, वह है प्रत्येक बचत पर कैश्ड टाइमस्टैम्प को अपडेट करना। यह कैश को तरोताजा रखेगा। मैं सहेजते समय सीधे डीबी से टाइमस्टैम्प की जांच करता हूं ताकि पुराने कैश डेटा के कारण एक सेव स्नीकिंग को रोकने के लिए सहेजा जा सके।
यदि आप कैशिंग के लिए एपीसी का उपयोग करते हैं, तो दूसरा HTTP सर्वर समझ में नहीं आता है - आपको इसे उसी मशीन पर चलाना होगा (एपीसी साझा स्मृति का उपयोग करता है)। वही भौतिक मशीन काम कर रही होगी, लेकिन दूसरे HTTP सर्वर के अतिरिक्त ओवरहेड के साथ। यदि आप मतदान अनुरोधों को दूसरे सर्वर (आपके मामले में lighttpd) पर लोड करना चाहते हैं, तो बेहतर होगा कि अपाचे के सामने दूसरी भौतिक मशीन पर lightttpd को सेटअप किया जाए और एक साझा कैशिंग सर्वर (memcache) का उपयोग किया जाए ताकि लाइटटैप सर्वर कैश्ड टाइमस्टैम्प को पढ़ सकता है, और अपाचे कैश्ड टाइमस्टैम्प को अपडेट कर सकता है। Apache के सामने lighttpd लगाने का औचित्य है, यदि अधिकांश अनुरोध मतदान अनुरोध हैं, तो भारी-भार वाली Apache प्रक्रिया के उपयोग से बचने के लिए।
आपको शायद दूसरे सर्वर की बिल्कुल भी आवश्यकता नहीं है। अपाचे अतिरिक्त अनुरोधों को संभालने में सक्षम होना चाहिए। यदि ऐसा नहीं हो सकता है, तो मैं आपके कॉन्फ़िगरेशन (विशेष रूप से निर्देश जो नियंत्रित करता हूं कि आप कितनी कार्यकर्ता प्रक्रियाएं चलाते हैं और मारे जाने से पहले उन्हें कितने अनुरोधों को संभालने की अनुमति है) पर फिर से विचार करेंगे।
