क्या सत्रों को अधिक कुशलता से साझा करने के लिए मेमकेच डेमों का पूल इस्तेमाल किया जा सकता है?


25

हम 1 वेबसर्वर सेटअप से दो वेबसर्वर सेटअप पर जा रहे हैं और मुझे दो लोड संतुलित मशीनों के बीच PHP सत्र साझा करना शुरू करना है। हमने पहले से ही स्थापित ( और शुरू किया ) मेमस्कैलेट किया है और इसलिए मुझे सुखद आश्चर्य हुआ कि मैं फ़ाइल में केवल 3 पंक्तियों को बदलकर नए सत्र के बीच साझाकरण सत्र को पूरा कर सकता हूं ( session.save_handler और session.save_path :php.ini

मैंने प्रतिस्थापित किया:

session.save_handler = files

साथ में:

session.save_handler = memcache

फिर मास्टर वेबसर्वर पर मैंने session.save_pathलोकलहोस्ट को इंगित करने के लिए सेट किया :

session.save_path="tcp://localhost:11211"

और गुलाम वेबसर्वर पर मैंने session.save_pathमास्टर को इंगित करने के लिए सेट किया :

session.save_path="tcp://192.168.0.1:11211"

नौकरी की, मैंने इसका परीक्षण किया और यह काम करता है। परंतु...

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

मास्टर:

session.save_path="tcp://localhost:11211, tcp://192.168.0.2:11211"

दास:

session.save_path="tcp://localhost:11211, tcp://192.168.0.1:11211"

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

नोट : मैं वास्तव में विशेष रूप से मेमकेच प्रतिकृति के बारे में नहीं पूछ रहा हूं - इसके बारे में और अधिक कि क्या PHP मेम्चेचे क्लाइंट प्रत्येक मेम्चेचे डेमॉन के अंदर एक पूल में चोटी कर सकता है, एक सत्र को वापस करता है यदि यह एक पाता है और केवल एक नया सत्र बनाता है यदि यह नहीं मिलता है सभी दुकानों में। जैसा कि मैं यह लिख रहा हूँ मैं सोच रहा हूँ कि मैं PHP, lol से थोड़ा बहुत पूछ रहा हूँ ...

मान लें : कोई चिपचिपा सत्र, राउंड-रॉबिन लोड संतुलन, LAMP सर्वर।


1
Memcache प्रलेखन सत्र भंडारण के लिए Memcache का उपयोग करने की अनुशंसा नहीं करता है। कोड देखें। http://www.p/memcached/wiki/… !

जवाबों:


37

अस्वीकरण: आप परीक्षण के एक टन के बिना मुझे सुनने के लिए पागल हो जाएगा और किसी योग्य से 2 राय प्राप्त करना - मैं इस खेल के लिए नया हूं

इस प्रश्न में प्रस्तावित दक्षता सुधार विचार काम नहीं करेगा। मैंने जो मुख्य गलती की, वह यह सोचना था कि पूल में निर्धारित स्टोरों को जिस क्रम में परिभाषित किया गया है वह किसी प्रकार की प्राथमिकता तय करता है। ऐसी बात नहीं है । जब आप याद किए गए डेमोंस (उदाहरण का उपयोग करके session.save_path="tcp://192.168.0.1:11211, tcp://192.168.0.2:11211") के एक पूल को परिभाषित करते हैं, तो आप यह नहीं जान सकते कि किस स्टोर का उपयोग किया जाएगा। डेटा समान रूप से वितरित किया जाता है, जिसका अर्थ है कि एक आइटम पहले में संग्रहीत किया जा सकता है, या यह अंतिम हो सकता है (या यह दोनों हो सकता है यदि मेमकेच क्लाइंट को दोहराने के लिए कॉन्फ़िगर किया गया है - ध्यान दें कि यह क्लाइंट है जो प्रतिकृति को संभालता है, मेम्केड सर्वर करता है अपने आप नह) ं है। किसी भी तरह से इसका मतलब यह होगा कि पूल में पहली बार लोकलहोस्ट का उपयोग करने से प्रदर्शन में सुधार नहीं होगा - या तो स्टोर को हिट करने का 50% मौका है।

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

जब तक आपके पास PHP एप्लिकेशन नहीं है, तब तक निम्नलिखित पर ध्यान न दें:


टिप 1: यदि आप मेम्के का उपयोग करके 2 सर्वरों पर सत्र साझा करना चाहते हैं:

सुनिश्चित करें कि आपने " मेमेचे सेशन हैंडलर सपोर्ट सक्षम करें " के लिए हां में उत्तर दिया है, जब आपने PHP मेम्चेच क्लाइंट स्थापित किया है और अपनी फाइल में निम्नलिखित जोड़ें :/etc/php.d/memcache.ini

session.save_handler = memcache

वेबसर्वर 1 पर (आईपी: 192.168.0.1):

session.save_path="tcp://192.168.0.1:11211"

वेबसर्वर 2 पर (आईपी: 192.168.0.2):

session.save_path="tcp://192.168.0.1:11211"

टिप 2: यदि आप मेम्के का उपयोग करके 2 सर्वरों में सत्र साझा करना चाहते हैं और उनके पास विफलता का समर्थन है:

अपनी /etc/php.d/memcache.iniफ़ाइल में निम्न जोड़ें :

memcache.hash_strategy = consistent
memcache.allow_failover = 1

वेबसर्वर 1 पर (आईपी: 192.168.0.1):

session.save_path="tcp://192.168.0.1:11211, tcp://192.168.0.2:11211"

वेबसर्वर 2 पर (आईपी: 192.168.0.2):

session.save_path="tcp://192.168.0.1:11211, tcp://192.168.0.2:11211"

टिप्पणियाँ:

  • यह मूल प्रश्न में की गई एक और गलती को उजागर करता है - मैं session.save_pathसभी सर्वरों पर एक समान का उपयोग नहीं कर रहा था ।
  • इस मामले में "फेलओवर" का मतलब है कि एक मेमेचे डेमन को विफल होना चाहिए, PHP मेम्चेचे क्लाइंट दूसरे का उपयोग करना शुरू कर देगा। अर्थात स्टोर में अपना सत्र जो कोई भी विफल हो गया, उसे लॉग आउट किया जाएगा। यह पारदर्शी विफलता नहीं है।

टिप 3: यदि आप मेम्के का उपयोग करके सत्र साझा करना चाहते हैं और पारदर्शी विफलता का समर्थन करते हैं:

टिप 2 के समान ही आपको अपनी /etc/php.d/memcache.iniफ़ाइल में निम्न जोड़ने की आवश्यकता है :

memcache.session_redundancy=2

टिप्पणियाँ:

  • यह PHP मेम्चेचे क्लाइंट को 2 सर्वरों को सत्र लिखने देता है। आपको अतिरेक मिलता है (जैसे RAID-1) ताकि एन दर्पणों पर लिखा जाए और get'sदर्पणों पर विफल रहे। इसका मतलब यह होगा कि उपयोगकर्ता एक मेम्केचे डेमन की विफलता के मामले में अपने सत्र को ढीला नहीं करते हैं।
  • मिरर किए गए लेखन समानांतर में किए जाते हैं (गैर-अवरोधक-आईओ का उपयोग करके) इसलिए गति प्रदर्शन को बहुत नीचे नहीं जाना चाहिए क्योंकि दर्पण की संख्या बढ़ जाती है। हालाँकि, नेटवर्क ट्रैफ़िक बढ़ेगा यदि आपके मेकचे दर्पण विभिन्न मशीनों पर वितरित किए गए हैं। उदाहरण के लिए, अब लोकलहोस्ट का उपयोग करने और नेटवर्क के उपयोग से बचने का 50% मौका नहीं है।
    • जाहिर है, लिखने में देरी के कारण पुराने डेटा को कैश मिस के बजाय पुनर्प्राप्त किया जा सकता है। सवाल यह है कि क्या यह आपके आवेदन के लिए मायने रखता है? आप सत्र डेटा को कितनी बार लिखते हैं?
  • memcache.session_redundancyसत्र अतिरेक के लिए है, लेकिन एक memcache.redundancyini विकल्प भी है जो आपके PHP अनुप्रयोग कोड द्वारा उपयोग किया जा सकता है यदि आप चाहते हैं कि यह अतिरेक का एक अलग स्तर हो।
  • आपको PHP मेम्काचे क्लाइंट के हाल के संस्करण (अभी भी इस समय बीटा में) की आवश्यकता है - pecl से संस्करण 3.0.3 ने मेरे लिए काम किया।

क्या आप "यह एक साझा डेटाबेस का उपयोग करने के साथ-साथ पैमाने पर नहीं" पर टिप्पणी कर सकते हैं? मैं यह नहीं देखता कि यह एक विशिष्ट मास्टर-दास डीबी सेटअप से कैसे अलग है। धन्यवाद!
बॉय बुकेमा

यह एक बहुत अच्छा ब्रेकडाउन है, हालांकि अफवाहें (उर्फ बग रिपोर्ट) हैं कि यह अपेक्षित नहीं है जब आप ext/memcacheसंस्करण 3.00 का उपयोग करते हैं । हम उस विकल्प के साथ भी खेल रहे हैं और मैंने सर्वर सूची के माध्यम से लूप करने का फैसला किया है और इसे स्वयं लिखूंगा।
जब तक

टिप 3 के मामले में: क्या होगा यदि एक मेमेकैस्ट होस्ट नीचे जाता है और फिर ऊपर आता है, तो सेकंड होस्ट नीचे चला जाता है। जैसा कि मैं समझता हूं - कोई भी सत्र डेटा बहाल नहीं किया जाएगा और इसमें से कुछ खो जाएगा, है ना?
GioMac

28

पुन: टिप 3 ऊपर (किसी और के लिए जो Google के माध्यम से इस पर आने के लिए होता है), ऐसा लगता है कि कम से कम वर्तमान में यह काम करने के लिए आपको memcache.session_redundancy = N+1अपने पूल में एन सर्वर के लिए उपयोग करना होगा , कम से कम ऐसा लगता है कि न्यूनतम सीमा मूल्य जो काम करता है। (डेबियन स्थिर, पीईसीएल मेमेकैच 3.0.6 पर php 5.3.3 के साथ परीक्षण किया गया, दो मेमकास्टेड सर्वर session_redundancy=2जैसे ही मैं पहले सर्वर को बंद करता है save_path, session_redundancy=3ठीक काम करता है , विफल हो जाएगा ।)

ऐसा लगता है कि इन बग रिपोर्ट में कब्जा कर लिया गया है:


1
यदि आपके पास पर्याप्त वोट दें नहीं कर सकते ..
उत्सव

1
मुझे खुशी है कि मैंने नीचे स्क्रॉल किया। यही समस्या थी।
डैरन श्वेनेके

यह मेरे लिए स्पष्ट नहीं है, क्या यह सुविधा केवल PECL मेमेचे 3.x श्रृंखला में उपलब्ध है? उन सभी को pecl.php.net/package/memcache पर बीटा सॉफ्टवेयर में सूचीबद्ध किया गया है , जबकि 2.2.7 पर अगर मैं उस सर्वर को मारता हूं जिस पर मैं नेता को देखता हूं, तो सब कुछ मर जाता है।
जो

यह साल हो गया है जब मैंने इसे देखा, ईमानदार होना। जैसा कि मुझे याद है, यह एक 3.x फीचर (icbw) था। हमने उस प्लगइन के "बीटा" संस्करणों (उनमें से कुछ काफी उच्च ट्रैफ़िक) का उपयोग करके कई सिस्टमों को तैनात किया और कोई भी समस्या नहीं थी जो उस से संबंधित थी। YMMV, चीजों को लाइव करने से पहले परीक्षण करें, आदि :) मैं PHP में कुछ वर्षों से काम नहीं कर रहा था, इसलिए सामान्य ज्ञान के कुछ महीन बिंदु फीके पड़ने लगे हैं।
माइकल जैक्सन

3

ऊपर दिखाए गए php.ini सेटिंग्स के साथ-साथ निम्नलिखित भी निर्धारित हैं:

memcache.allow_failover = 1  
memcache.hash_strategy = 'consistent'

फिर आपको पूर्ण विफलता और क्लाइंट-साइड अतिरेक मिलेगा। इस दृष्टिकोण के साथ चेतावनी यह है कि अगर मेमॉश्ड लोकलहोस्ट पर डाउन है, तो php मेम्चे कैश क्लाइंट सेशन में निर्दिष्ट सर्वर से पहले प्रयास करने से पहले हमेशा एक रीड मिस होगा। सत्र_पठ

बस ध्यान रखें कि यह आपके वेब सर्वर पर चल रहे php मेमकेक क्लाइंट के लिए वैश्विक सेटिंग्स को प्रभावित करता है।


क्या consistentहैशिंग रणनीति का उपयोग करने से यह समझ में आता है कि session.save_pathप्रत्येक वेबसर्वर पर अलग है?
टॉम

1

मेम्केड उस तरह से काम नहीं करता है (कृपया गलत होने पर मुझे सही करें!)

यदि आप चाहते हैं कि आपके आवेदन में अनावश्यक सत्र भंडारण हो, तो आपको कुछ ऐसा बनाना होगा जो दोनों संचित उदाहरणों में प्रविष्टियाँ जोड़ / मिटा / हटा दे। memcached इसे हैंडल नहीं करता है, केवल यह प्रदान करता है कुंजी हैश भंडारण के रूप में है। तो कोई प्रतिकृति, तुल्यकालन, कुछ नहीं, नाडा।

मुझे उम्मीद है कि मैं इस मामले में गलत नहीं हूं, लेकिन यह वही है जो मुझे पता है कि मैंने इसे छुआ था, कुछ साल हो गए हैं।


यदि आप गलत थे तो यह मेरे लिए उपयोगी होगा। :-) phpslacker.com ( phpslacker.com/2009/03/02/php-session-clustering-with-memcache ) में एक लेख है जो बताता है कि मेमकेड प्रश्न में वर्णित के अनुसार काम कर सकता है। शायद यह निर्भर करता है कि मेमचैच क्लाइंट हैशिंग रणनीति को कैसे लागू करता है?
टॉम

1
memcache उस तरह से काम नहीं करता है, लेकिन ऐसा लगता है कि php आपके इच्छित तरीके से काम कर सकता है। आपको php.ini को बदलना होगा या अपने ऐप को बताए अनुसार बदलना होगा। ब्लॉग से: जहाँ आप पूछ रहे हैं कि अच्छा है, सच कहा जाए तो कोई बात नहीं है। हमारे पास अब तक 2 सर्वरों वाला एक मेमच पूल है। PHP को पूल में लिखने के लिए कॉन्फ़िगर किया गया है। PHP, "session.save_path" ini निर्देश द्वारा निर्दिष्ट क्रम में सर्वर पूल को पढ़ता / लिखता है। पठन के लिए PHP पूल से कुंजी द्वारा कैश ऑब्जेक्ट का अनुरोध करेगी। क्योंकि "फेलओवर" सक्षम है PHP
मेकचे

1

मेम्केच्ड बॉक्स से बाहर नहीं निकलता है, लेकिन repcached (एक पैच मेम्केड ) करता है। हालाँकि यदि आप पहले से ही mysql का उपयोग कर रहे हैं तो क्यों न केवल मास्टर-मास्टर प्रतिकृति के साथ इसकी प्रतिकृति कार्यक्षमता का उपयोग करें और पूर्ण प्रतिकृति प्रतिकृति का लाभ प्राप्त करें।

सी।


जानकारी के लिए धन्यवाद। यह वास्तव में प्रतिकृति नहीं है कि मैं इसके बाद हूं। जब तक सत्र नहीं मिल जाता, तब तक प्रत्येक ज्ञापन को चरम पर रखने की इच्छा है। यानी पहले लोकलहोस्ट को चेक करना क्योंकि यह सबसे तेज़ है और फिर दूसरे सर्वर की जाँच कर रहा है।
टॉम

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

प्रतिक्रिया के लिए धन्यवाद, हां, मैं स्वतंत्र रूप से मानता हूं कि मैं सत्र साझा करने में एक नॉब हूं! :-) हालाँकि, मुझे अभी तक समझ नहीं आया है कि मेरा प्रस्ताव इतना बदसूरत क्यों है। मैंने सोचा कि एक साझा DB का उपयोग करने की तुलना में यह अधिक कुशल होगा और मुझे भी लगा कि इससे आउटेज कम होने की संभावना है।
टॉम

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

मैंने परीक्षण किया है और पुष्टि की है कि जब तक मैं allow_failover = 1 का उपयोग कर रहा हूं, तब तक कई दर्पण कम से कम संभावनाएं बनाते हैं। मैं एक दर्पण को बंद कर सकता हूं, इसे पुनरारंभ कर सकता हूं और दूसरे को बंद कर सकता हूं, इसे फिर से शुरू कर सकता हूं और पहले बंद कर सकता हूं - बिना लॉग आउट किए सभी। मुझे लगता है कि PHP memcache क्लाइंट पर्दे के पीछे चालबाजी का एक बहुत कुछ कर रहा है।
टॉम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.