php कई सर्वरों पर AWS ElastiCache के साथ ज़ेंड कैश का उपयोग करके असंगत कैश मान




zend-framework caching (2)

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

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

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

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

$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);

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

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

सर्वर ए $cache->save('hello', 'message'); निष्पादित करता है $cache->save('hello', 'message');

बाद में कॉल $cache->load('message'); सर्वर ए से हैलो के अपेक्षित परिणाम लौटाते हैं।

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

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


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

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





amazon-elasticache