30

हम ज़ेड कैश का उपयोग एक कैश नोड्स के साथ एक एडब्ल्यूएस एलिस्टी कैश क्लस्टर को इंगित करने वाले एक मेमकैच बैकएंड के साथ कर रहे हैं। हमारे कैश सेटअप इस तरह दिखता है:एकाधिक सर्वरों पर AWS ElastiCache के साथ ज़ेंड कैश का उपयोग करके असंगत कैश मान

$frontend = array(
    'lifetime' => (60*60*48), 
    'automatic_serialization' => true, 
    'cache_id_prefix' => $prefix 
); 
$backend = array(
    'servers' => array(
     array('host' => $node1), 
     array('host' => $node2) 
    ) 
); 
$cache = Zend_Cache::factory('Output', 'memecached', $frontend, $backend); 

हम अतीत में कैश के साथ कोई समस्या है जब एक ही EC2 सर्वर लिख सकते हैं और कैश से पढ़ने के लिए का उपयोग कर नहीं दिखाई दी।

हालांकि, हमने हाल ही में एक दूसरा ईसी 2 सर्वर पेश किया है और अचानक हम एक सर्वर से कैश को लिखते समय और दूसरे से पढ़ने के दौरान मुद्दों को देख रहे हैं। दोनों सर्वर एक ही एडब्लूएस खाते द्वारा प्रबंधित होते हैं, और न ही सर्वर को अलग-अलग कैश से लिखने या पढ़ने में समस्याएं होती हैं। दोनों के लिए एक ही कैश विन्यास का उपयोग किया जाता है।

सर्वर एक कार्यान्वित सर्वर एक से $cache->load('message'); को $cache->save('hello', 'message');

बाद कॉलहैलो के अपेक्षित परिणाम वापस जाएँ।

हालांकि, जब सर्वर बी$cache->load('message'); कार्यान्वित करता है, हम झूठी मिलता है।

जहां तक ​​ElastiCache की मेरी समझ जाती है, सर्वर को पढ़ने के अनुरोध को वापस करने वाले कैश मान पर कोई असर नहीं होना चाहिए। क्या कोई इस पर रोशनी डाल सकता है?

+0

मुझे लगता है कि यह एक विलंबता मुद्दा है, क्या आपने सोने की कोशिश की है (xxxx) और उसके बाद $ कैश-> बी से लोड करें? –

+0

दुर्भाग्यवश, यह मामला नहीं है। यहां तक ​​कि घंटों बाद भी ए से एक मूल्य सेट बी से पठनीय नहीं है। – michaelxor

+0

PHP का कौन सा संस्करण आप उपयोग कर रहे हैं? मुझे लगता है कि धारावाहिकता यहां खेल में है। ऑटो धारावाहिकता को अक्षम करने का प्रयास करें और देखें कि क्या होता है। दुर्भाग्यपूर्ण दुष्प्रभाव यह है कि आपको मैन्युअल रूप से सब कुछ क्रमबद्ध करना है जो एक स्ट्रिंग नहीं है। –

उत्तर

1

क्या आप बता सकते हैं कि क्या हैश_स्ट्रेटी आप memcache के लिए उपयोग कर रहे हैं? मैं डिफ़ॉल्ट मानक का उपयोग कर अतीत में समस्या नहीं थी है, लेकिन सब कुछ बदल रहा है के बाद से ठीक संगत लिए है:

http://php.net/manual/en/memcache.ini.php#ini.memcache.hash-strategy

0
एक सामान्य हैशिंग एल्गोरिथ्म के साथ

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

कल्पना कीजिए कि आपके कैश क्लस्टर में 5 एलिस्टी कैश नोड्स हैं, एक छठा सर्वर जोड़कर आपकी चाबियों का 40% + अचानक सामान्य से अलग सर्वर पर इंगित कर सकता है। यह गतिविधि अवांछित है, कैश मिस का कारण बन सकती है और अंततः अनुरोधों के साथ आपके बैकएंड डीबी को स्वैप कर सकती है। इस रीमेपिंग को कम करने के लिए आपके कैश क्लाइंट में लगातार हैशिंग मॉडल का पालन करने की अनुशंसा की जाती है।

संगत हैशिंग एक ऐसा मॉडल है जो सर्वरों को जोड़ने या हटाने के लिए कुंजी के अधिक स्थिर वितरण की अनुमति देता है। लगातार हैशिंग सर्वर की सूची में मैपिंग कुंजियों के तरीकों का वर्णन करती है, जहां सर्वर जोड़ना या निकालना कारणों को मानचित्र में बहुत कम शिफ्ट का कारण बनता है। इस दृष्टिकोण का उपयोग करते हुए, ग्यारहवें सर्वर को जोड़ने से आपकी कुंजी का 10% से कम पुन: असाइन किया जाना चाहिए। यह% उत्पादन में भिन्न हो सकता है लेकिन यह सामान्य हैश एल्गोरिदम की तुलना में इस तरह के लोचदार परिदृश्यों में कहीं अधिक कुशल है। यह लगातार हैशिंग का उपयोग करते समय सभी क्लाइंट कॉन्फ़िगरेशन में memcached सर्वर ऑर्डरिंग और सर्वरों की संख्या को रखने की भी सलाह दी जाती है। जावा एप्लिकेशन अपने सिस्टम में इस एल्गोरिदम को एकीकृत करने के लिए spymemcached के माध्यम से "केटामा लाइब्रेरी" का उपयोग कर सकते हैं। लगातार हैशिंग पर अधिक जानकारी http://www.last.fm/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients

संबंधित मुद्दे