Node-redis: प्रहरी जागरूक

+1, इस नोड_रेडिस क्लाइंट के शीर्ष पर एक रैपर क्यों नहीं बनाते? यदि आप इस पर काम करना शुरू करते हैं तो कृपया मुझे बताएं क्योंकि मैं उस भंडार को तारांकित करना चाहूंगा।

नमस्ते,

मैंने इस पर काम करना शुरू कर दिया है, परिणाम https://github.com/tanguylebarzic/node_redis पर चेक किया जा सकता है
उपयोग का एक उदाहरण:

var RedisMetaClient = require("./../node_redis/sentinel").RedisMetaClient;
var sentinels = [
    {host: "127.0.0.1", port: 26382},
    {host: "127.0.0.1", port: 26383},
    {host: "127.0.0.1", port: 26384}
];
var redisMetaClient = new RedisMetaClient("mymaster", sentinels);
var i = 0;

var client = redisMetaClient.createMasterClient();
client.on('error', function(error){
    console.log(error);
});

setInterval(function(){
    client.set('test:' + i, i, function(error, result){
        if(!error){
            console.log('success, ' + i);
            ++i;
        }
        else {
            console.log('error, ' + i);
        }
   });
}, 500);

मूल रूप से, आपको सबसे पहले एक 'RedisMetaClient' बनाना होगा, जिसे मास्टर के नाम और प्रहरी की सूची के साथ कॉन्फ़िगर किया गया हो। फिर, redisMetaClient.createMasterClient(); कॉल करने से आपको सामान्य redis.createClient(); समान क्लाइंट मिलेगा

क्या काम करता है:

• बुनियादी कार्यक्षमता, यानी। सही मास्टर का सेटअप, फेलओवर... यदि मास्टर बदल जाता है, तो सभी मौजूदा मास्टर क्लाइंट ( redisMetaClient.createMasterClient(); द्वारा बनाए गए) नए मास्टर को इंगित करने के लिए अपडेट किए जाएंगे, ताकि किसी को क्लाइंट की तलाश करने की आवश्यकता न हो। on('error') कनेक्शन को अपडेट करने के लिए।
  मैंने ऑफ़लाइन कतार के विचार को संरक्षित करने का प्रयास किया है, यानी। मास्टर के मिलने और कॉन्फ़िगर होने से पहले कमांड भेजने में सक्षम होना।
• मैंने सरल अनुरोधों, पब/उप के साथ परीक्षण किया है ... लेकिन बहु के साथ नहीं (काम कर सकता है, बस सुनिश्चित नहीं है)।

यह कैसे किया जाता है:
मैंने एकल क्लाइंट के कोड और व्यवहार को यथासंभव कम संशोधित करने का प्रयास किया है ('क्लाइंट.जेएस' में क्या है)। Sentinel.js में प्रहरी से निपटने के लिए, client.js के चारों ओर एक प्रकार का आवरण होता है।

क्या किया जाना बाकी है:

• दासों के साथ व्यवहार (अभी के लिए, उनके आसपास कुछ भी नहीं किया जाता है)।
• कई परिदृश्यों का परीक्षण (हाथ से और स्वचालित दोनों)
• प्रलेखन

ज्ञात पहलु:

• घटना ready एक मास्टर क्लाइंट के लिए कई बार ट्रिगर किया जाता है यदि एक विफलता हुई, जिसके परिणामस्वरूप अप्रत्याशित व्यवहार हो सकता है जिस तरह से इसका उपयोग किया जाता है
• कई अन्य जिनके बारे में मुझे नहीं पता

tanguylebarzic, प्रहरी समर्थन से निपटने के लिए शुरू करने के लिए धन्यवाद। मैं आपके दृष्टिकोण से भ्रमित हूं, हालांकि: आप अपने नोड.जेएस कोड में सेंटीनेल कार्यक्षमता (उदाहरण के लिए मास्टर और दासों की पहचान करना, एक कोरम संभालना) को लागू कर रहे हैं। लेकिन प्रहरी डॉक्स में जो रेडिस-सेंटिनल डेमॉन के config. नोड को इस बात की परवाह नहीं करनी चाहिए कि किसी दिए गए प्रहरी के लिए गुरु या दास कौन हैं, इसे केवल प्रहरी से जुड़ना चाहिए, जो पहले से ही सभी को संभाल रहा है। (और उस SentinelClient को एक नियमित RedisClient की तरह व्यवहार करना चाहिए, इसलिए यह पीछे की ओर-कनेक्ट-रेडिस सत्र स्टोर, आदि के साथ संगत है)

क्या आप अपना दृष्टिकोण स्पष्ट कर सकते हैं? धन्यवाद!

मैंने RedisSentinelClient साथ एक वैकल्पिक दृष्टिकोण लागू करना शुरू कर दिया है जो पारदर्शी रूप से RedisClient तरह व्यवहार करता है: https://github.com/DocuSignDev/node_redis

हमेशा प्रतिक्रिया, सुझावों और/या सहयोगियों में रुचि रखते हैं।

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

@newleafdigital : मैंने

io.set('store', new socketio.RedisStore({
    redis: redis,
    redisPub:   redis.createClient( 26379, "127.0.0.1", {sentinel: true} ),
    redisSub:   redis.createClient( 26379, "127.0.0.1", {sentinel: true} ),
    redisClient:redis.createClient( 26379, "127.0.0.1", {sentinel: true} )
 }));

स्टार्टअप पर मेरा ऐप क्रैश:

 Error: Redis connection to 127.0.0.1:6379 failed - connect ECONNREFUSED
     at RedisClient.on_error (/home/green/debug/node_modules/redis/index.js:168:24)
     at Socket.RedisClient.initialize_stream_listeners.stream.on.self.should_buffer (/home/green/debug/node_modules/redis/index.js:93:14)
     at Socket.EventEmitter.emit (events.js:96:17)
     at Socket._destroy.self.errorEmitted (net.js:328:14)
     at process.startup.processNextTick.process._tickCallback (node.js:244:9)
 [Wed, 13 Feb 2013 16:46:56 GMT] INFO worker 6622 died

कृपया ध्यान रखें कि त्रुटि संदेश यह बताता है कि कनेक्शन 26379 के बजाय 6379 को पोर्ट करने में विफल रहा !!!

कोई विचार क्या समस्या हो सकती है? जब मैं सीधे रेडिस-सर्वर (मास्टर) से जुड़ता हूं तो सब कुछ ठीक होता है।

पैरामीटर के लिए एक हैश का उपयोग करने का प्रयास करें:

redis.createClient({ port: 26379, host: "127.0.0.1", sentinel: true } );

जब आप प्रहरी से redis-cli -p 23679 (मास्टर - प्रहरी != मास्टर से नहीं) के माध्यम से जुड़ते हैं, तो क्या यह कनेक्ट होता है?

१) हाँ, redis-cli -p 26379 माध्यम से प्रहरी से जुड़ना सफलतापूर्वक जुड़ जाता है।
2) वैकल्पिक सिंटैक्स का उपयोग कनेक्ट पर क्रैश नहीं होता है, लेकिन redisSentinelClient के पहले get पर एक त्रुटि देता है:

[Error: ERR unknown command 'get']

उस स्थिति में मैंने सामान्य रेडिस कार्यक्षमता का उपयोग किया (सॉकेट.io नहीं)।

हह्ह्ह्म। हो सकता है कि आपके मॉड्यूल की कोई समस्या न हो .... जब मैं प्रहरी से जुड़ता हूं तो यह सफलतापूर्वक जुड़ जाता है, लेकिन यह किसी भी रेडिस कमांड को नहीं जानता है:

green<strong i="6">@mycomp1</strong>:~/redis/redis$ src/redis-cli -p 26379
redis 127.0.0.1:26379> set test 1
(error) ERR unknown command 'set'
redis 127.0.0.1:26379>

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

अतिरिक्त: दस्तावेज़ों को और विस्तार से पढ़ना मैंने देखा कि यह व्यवहार सामान्य है। लेकिन आपका ग्राहक ऐसा क्यों करता है? क्या इसे "सामान्य" रेडिस क्लाइंट के रूप में व्यवहार नहीं करना चाहिए?

प्रहरी को स्वयं प्राप्त/सेट/आदि को संभालना नहीं चाहिए, लेकिन प्रहरी _client_ को इसे मास्टर को सौंपकर इसे संभालना चाहिए।
क्या आप सेंटिनल क्लाइंट कंस्ट्रक्टर में कुछ डिबगिंग कोड डाल सकते हैं, यह सुनिश्चित करने के लिए कि यह सेंटिनल क्लाइंट को इंस्टेंट कर रहा है और नियमित क्लाइंट नहीं है?
एक प्रहरी परीक्षण सूट भी है जिसे हमने जोड़ा, मोचा के साथ चलाएं - शायद इसे चलाएं (बंदरगाह बदलना) और देखें कि क्या वे आपके सिस्टम पर गुजरते हैं?

धन्यवाद

@newleafdigital : क्या यह संभव है कि आप सेंटीनेल को उसी मशीन में रेडिस के रूप में चलाने की अपेक्षा करें? मेरे पास एक अलग मशीन पर मेरा प्रहरी चल रहा है (जिस पर नोड चलता है) और मुझे संदेह है कि यह परिदृश्य वर्तमान कार्यान्वयन के लिए काम करता है। मुझे अभी भी त्रुटि मिलती है

 Error: Redis connection to 127.0.0.1:6379 failed - connect ECONNREFUSED

और यह मुझे इस निष्कर्ष पर ले जाता है कि यह 127.0.0,1 === इस मशीन पर रेडिस इंस्टेंस से कनेक्ट करने का प्रयास करता है।

यह आपके क्लाइंट को socket.io के साथ उपयोग करने की एक विशिष्ट समस्या प्रतीत होती है। क्या आपने कभी दोनों को एक साथ टेस्ट किया?

@newleafdigital : अब मुझे पता चल गया है कि क्या हो रहा है। मैंने आपके कोड में गहराई से खुदाई नहीं की लेकिन मैं व्यवहार का बिल्कुल वर्णन कर सकता हूं:

मेरे वर्तमान कॉन्फ़िगरेशन में (मशीन 1 पर नोड-ऐप, मशीन 2 पर रेडिस_मास्टर 2, मशीनों पर रेडिस_स्लेव्स 3 + 4, मशीनों पर रेडिस_सेंटिनल्स 2 + 3 + 4) आपका कोड केवल तभी काम करता है जब मैं मशीन 3 + 4 पर स्लेव_सेंटिनल्स में से एक से जुड़ता हूं। अगर मैं मास्टर (मशीन 2) पर प्रहरी से जुड़ता हूं तो यह काम नहीं करता है।

जब मैं दो गुलामों में से एक से जुड़ता हूं तो सिस्टम सही ढंग से लॉग करता है:

debug connected to sentinel listener
debug connected to sentinel talker
debug new master info { host: 'the.ip.of.master', port: '6379' }
debug Changing master from 127.0.0.1:9999 to the.ip.of.master:6379
debug New master is ready [Yippieee!]

जब मैं मास्टर पर प्रहरी से जुड़ता हूं तो यह कहता है (और बाद में काम नहीं करता है):

debug connected to sentinel listener
debug connected to sentinel talker
debug new master info { host: '127.0.0.1', port: '6379' } 
debug Changing master from 127.0.0.1:9999 to 127.0.0.1:6379

और नहीं debug New master is ready । जैसा कि आप देख सकते हैं, जब मैं मास्टर के प्रहरी से जुड़ता हूं, तो मास्टर को सही ढंग से संबोधित नहीं किया जाता है ( सही आईपी के बजाय 127.0.0.1 )।

यदि प्रहरी अन्य मशीनों पर चलते हैं, लेकिन रेडिस की मशीनें (यानी नोड-ऐप जैसी ही मशीन पर - जैसा कि मेरे पहले कॉन्फ़िगरेशन में है) तो यह केवल तभी काम करती है, जब प्रहरी दासों में से एक से जुड़ा हो (और नहीं गुरुजी)।

और...एक साथ wird socket.io/RedisStore यह किसी भी तरह से (मेरी कॉन्फ़िगरेशन के संबंध में) काम नहीं करता है, भले ही मैं दासों में से एक पर प्रहरी से जुड़ता हूं।

+1 यह एक अलग मॉड्यूल के रूप में बहुत अच्छा है क्योंकि इसके बदलने की अधिक संभावना है।

यदि आप विकी में अपने मॉड्यूल का उल्लेख करना चाहते हैं, तो इसके लिए एक टैग के साथ आएं जैसे #redis-sentinel और फिर
मैं README में उस टैग के साथ सभी पैकेजों में एक लिंक जोड़ूंगा जैसे https://npmjs.org/browse/keyword/redis-sentinel

यहां सभी फीडबैक के लिए धन्यवाद, और खेद है कि मुझे गहराई से उत्तर देने का मौका नहीं मिला। मैंने इसके लिए अगले सप्ताह (4 मार्च) के लिए समय आवंटित किया है।

@DTrejo , आप इसे अपना मॉड्यूल बनाने के बारे में सही हैं, मुझे लगता है कि मैं ऐसा करूँगा (अगले सप्ताह भी)।

हाय दोस्तों

मैं इसे भी देख रहा हूं (मुझे प्रहरी की सूची से मास्टर प्राप्त करने के लिए कनेक्ट करने में सक्षम होना चाहिए और पुराने के नीचे जाने पर एक नए मास्टर से फिर से कनेक्ट होना चाहिए)।

मैंने मौजूदा RedisClient रीकनेक्शन सामान का उपयोग करके और वांछित होस्ट/पोर्ट को

इस पद्धति के फायदे यह हैं कि यह नोड_रेडिस पर सिर्फ एक आवरण है, इसलिए उस कोड के साथ नीचे उतरने और गंदा करने की कोई आवश्यकता नहीं है। इसके अलावा इसका मतलब यह होना चाहिए कि चूंकि ग्राहक लौटा एक (थोड़ा विस्तारित) RedisClient तो इसे मौजूदा कोड के साथ अच्छी तरह से स्लॉट करना चाहिए। और अंत में यह मौजूदा कोड की तुलना में आसान लगता है

मेरा कोड यहां है: https://github.com/ortoo/node-redis-sentinel - यह इस समय काफी सीमित है, लेकिन काफी एक्स्टेंसिबल लगता है। कोई भी विचार/दावा जो मैं गलत रास्ते पर जा रहा हूं उसकी सराहना की जाएगी।

वर्तमान कार्यक्षमता:

• प्रहरी समापन बिंदुओं और मास्टर नाम की सूची निर्दिष्ट करें
• एक RedisClient वापस प्राप्त करें जो मास्टर से जुड़ जाएगा
• यदि वर्तमान मास्टर मर जाता है तो RedisClient फिर से कनेक्ट करने का प्रयास करेगा (प्रहरी से मास्टर को हल करना)

:+1: प्रहरी पुस्तकालयों पर काम करने वाले सभी लोगों को! मुझे अभी तक देखने का मौका नहीं मिला है, लेकिन मैं इसे आजमाने के लिए उत्सुक हूं।

@jamessharp , नोड-रेडिस-सेंटिनल पर अच्छा काम। मैं यह पता लगाने की कोशिश कर रहा हूं कि क्या मुझे आपका अपनाना चाहिए या अपने सेंटिनल क्लाइंट को अपने मॉड्यूल में विभाजित करना चाहिए। एक चीज जो मैं आपके साथ नहीं समझ सकता, क्या इसका मतलब एक ऐसा क्लाइंट बनाना है जो पारदर्शी रूप से फेलओवर/रीकनेक्ट को संभालता है? या क्या ऐप को 3 क्लाइंट (मास्टर, स्लेव, सेंटीनेल) को तुरंत चालू करने और सक्रिय क्लाइंट के बीच स्विच करने की आवश्यकता होती है जब यह विफल हो जाता है?

उपरोक्त आपके विवरण से, यह पूर्व की तरह लगता है, लेकिन कोड को देखकर और इसका उपयोग करने का प्रयास करते हुए, यह बाद वाले की तरह लगता है।

धन्यवाद!

धन्यवाद। यह एक एकल क्लाइंट बनाने के लिए है जो पारदर्शी रूप से विफलता/पुनः कनेक्ट करता है। तीन क्लाइंट जो आपके पास हो सकते हैं (मास्टर/गुलाम/सेंटिनल) आपको विभिन्न प्रकारों में से प्रत्येक के लिए लगातार कनेक्शन देने के लिए हैं। इसलिए यदि आप दास से पढ़ने में प्रसन्न हैं तो आप एक दास कनेक्शन प्राप्त कर सकते हैं (जो एक नए दास उदाहरण से पारदर्शी रूप से पुन: कनेक्ट करने का प्रयास करेगा यदि आप जिस तक पहुंच रहे हैं वह नीचे चला जाता है)। यदि आपको मास्टर से स्थायी कनेक्शन की आवश्यकता है (जो भी सर्वर होता है) तो आप केवल मास्टर क्लाइंट का उपयोग कर सकते हैं और यदि आप सेंटीनेल इंस्टेंस से सीधा कनेक्शन चाहते हैं (जिसे फिर से पारदर्शी रूप से विफल होना चाहिए) तो आप सेंटीनेल क्लाइंट को पकड़ सकते हैं।

आशा है कि यह समझ में आता है।

बेशक अभी भी काफी काम है जिसे करने की जरूरत है लेकिन यह इस समय मेरे लिए काफी अच्छा काम करता है ...

त्वरित उत्तर @jamessharp के लिए धन्यवाद। बड़े लापता टुकड़े क्या हैं?

मैंने यह देखने के लिए यहां एक परीक्षण लिखा है कि यह कैसे काम करता है - https://gist.github.com/newleafdigital/5469571। स्क्रिप्ट चलाने से पहले, आप एक मास्टर+स्लेव+सेंटिनल शुरू करते हैं; स्क्रिप्ट मास्टर से जुड़ती है, और हर सेकंड एक हैश में एक वृद्धिशील कुंजी जोड़ता है। 5 सेकंड के बाद, गुरु को मार दिया जाता है, और यह देखने का विचार है कि क्या कुछ खो गया है। ऐसा लगता है कि मास्टर क्लाइंट वास्तव में कभी भी नए मास्टर से कनेक्ट नहीं होता है, इसलिए मुझे यकीन नहीं है कि मैं इसे गलत कर रहा हूं, या यदि यह काम नहीं कर रहा है।

फेलओवर के दौरान, क्या नुकसान से बचने के लिए डेटा को बफर करना चाहिए, या I/O फेलओवर के दौरान किया जाता है जिसे खो जाना चाहिए?

धन्यवाद

कुछ विचार यह क्यों काम नहीं कर रहे हैं:

• डिफ़ॉल्ट प्रहरी विन्यास वास्तव में तब तक विफल नहीं होगा जब तक कि मास्टर 30 सेकंड के लिए नीचे न हो (मुझे लगता है)
• क्लाइंट के पुन: संयोजन के प्रयासों के बीच का समय तेजी से बंद हो जाता है इसलिए पुन: कनेक्शन वास्तव में होने से एक मिनट पहले हो सकता है

मुझे यकीन नहीं है कि डेटा बफ़र किया गया है या नहीं। मुझे उम्मीद है लेकिन व्यवहार वही होगा जो कुछ भी होता है जब अंतर्निहित क्लाइंट फिर से कनेक्ट करने का प्रयास करता है।

मुख्य लापता टुकड़ा यह पता लगा रहा है कि मास्टर को नीचे जाने के बिना बदल दिया गया है (यानी मैन्युअल विफलता)। लेकिन पुन: संयोजन को यथासंभव तेज़ बनाने पर कुछ और काम किया जा सकता है।

मैंने तुलना करने के लिए हमारे कार्यान्वयन के साथ एक परीक्षण जोड़ा। परिणाम सार में हैं । विफलता के दौरान किए गए सभी I/O नोड-रेडिस-सेंटिनल के साथ खो जाते हैं, और हमारे (अधिक थोक) समाधान के साथ कोई डेटा नहीं

मुझे आपके समाधान की सादगी पसंद है, लेकिन मुझे आश्चर्य है कि क्या यह उन लक्ष्यों के लिए पर्याप्त है जिन्हें हम प्राप्त करने की उम्मीद कर रहे थे:

• redisClient के लिए पारदर्शी, ड्रॉप-इन प्रतिस्थापन
• सभी रेडिस क्लाइंट संचालन को संभालता है जिसमें पारदर्शी रूप से पब / उप शामिल हैं
• विफलता के दौरान डेटा की कोई हानि नहीं

अभी के लिए, मुझे लगता है कि हमारा कार्यान्वयन कुछ मूल्य जोड़ता है, और मैं इसे अपने मॉड्यूल में अलग कर दूंगा। यदि यह पता चलता है कि आपका अधिक सरल विकल्प पर्याप्त होगा, तो हम उस पर स्विच करेंगे।

अंतरिक्ष को समृद्ध करने के लिए धन्यवाद!

हाँ आपके लक्ष्य हाजिर हैं। हालांकि उनमें से बहुत से मूल node_redis क्लाइंट में वास्तव में उपयोगी होंगे। जब यह नीचे आता है तो एक एकल उदाहरण (यानी जो नोड_रेडिस वर्तमान में संभालता है) और एक प्रहरी नियंत्रित क्लस्टर में एक नए मास्टर/दास के लिए एक विफलता के बीच कोई अंतर नहीं होना चाहिए।

एक अलग मॉड्यूल में फेलओवर और पब/उप दृढ़ता के दौरान डेटा के नुकसान के लिए तर्क डालने के बजाय, मुझे लगता है कि हमें इसे मुख्य क्लाइंट में रखना चाहिए और फिर सेंटीनेल विशिष्ट तर्क के लिए एक अलग मॉड्यूल होना चाहिए (जिसकी तर्ज पर मैंने नोड-रेडिस-सेंटिनल में किया है)। इसकी जीत-जीत। यह एक बेहतर नोड_रेडिस क्लाइंट और एक सरल प्रहरी मॉड्यूल बनाता है।

मैंने कुछ चीजों को पूरा करने के लिए कोर node_redis क्लाइंट के रिफैक्टर पर काम करना शुरू कर दिया है: वर्तमान index.js को तोड़ दें ताकि काम करना थोड़ा आसान हो, लेकिन प्लगइन के लिए एक तंत्र में भी जोड़ना इसके जैसा। मैं सहमत हूं कि जिस तरह से node_redis कनेक्शन रुकावटों के लिए कमांड रिप्ले और ऑफ़लाइन कतार का प्रबंधन करता है, प्रहरी व्यवहार शायद मुख्य क्लाइंट के साथ सीधे काम करने के लिए सबसे अच्छा काम करता है।

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

मैं प्रतिक्रिया के लिए जल्द ही एक शाखा को आगे बढ़ाने की कोशिश करूंगा।

यह सब अच्छा लगता है लेकिन बहुत भारी है। नोड_रेडिस का हमारा संयोजन चरणों को संभालता है। मुझे यकीन नहीं है कि प्लग करने योग्य कनेक्शन प्रबंधक आवश्यक है।

दरअसल, सुधार: कांटे में सभी आवश्यक टुकड़े नहीं होते हैं; वे एक और प्रति में मौजूद हैं जिसे मुझे उस कांटे में विलय करने की आवश्यकता है। मैं इसे सोमवार (कल) को करूंगा।

मुझे पूरी तरह से यकीन नहीं है कि आप भारी से क्या मतलब रखते हैं - लक्ष्य एक लाइटर कोडबेस को प्रोत्साहित करना है जिससे उन्हें कोर लाइब्रेरी का हिस्सा बनने के लिए मजबूर किए बिना सुविधाओं को प्लग करना आसान हो जाता है।

मैंने अपने प्रहरी क्लाइंट कार्यान्वयन को एक नए मॉड्यूल, रेडिस-सेंटिनल-क्लाइंट में अलग किया :

https://github.com/DocuSignDev/node-redis-sentinel-client
https://npmjs.org/package/redis-sentinel-client

यह अभी भी node_redis में कुछ मामूली परिवर्तनों पर निर्भर करता है (इसलिए यह हमारे fork का उपयोग करता है); मैं केवल उन आवश्यक परिवर्तनों के लिए कांटा जोड़ूंगा, और उनके लिए पीआर जमा करूंगा।

( @brycebaril , मेरा मूल विचार यह था कि एक प्लग करने योग्य कनेक्शन प्रबंधक बेमानी/ओवरकिल होगा। मैं शायद इसके बारे में गलत हूं। मैं देखूंगा कि एक प्रहरी क्लाइंट को थोड़ी देर में समर्थन देने के लिए नोड_रेडिस के लिए वास्तव में कौन से परिवर्तन आवश्यक हैं।)

मैंने redis-sentinel-client का समर्थन करने के लिए दो पुल अनुरोध सबमिट किए हैं:

https://github.com/mranney/node_redis/pull/428 - निर्यात बर्तन और आदेश साझा करने के लिए (प्रहरी क्लाइंट, या अन्य के साथ) - यह गैर-ब्रेकिंग/कम-प्रभाव है और इस विशेष उपयोग की परवाह किए बिना नोड_रेडिस को बेहतर बनाता है .

https://github.com/mranney/node_redis/pull/429 - प्रहरी समर्थन के लिए लचीले कनेक्शन - यह संभावित रूप से अधिक ब्रेकिंग/विवादास्पद है और प्लग करने योग्य कनेक्शन प्रबंधकों के बारे में उपरोक्त धागे से संबंधित है।

प्रहरी समर्थन पर @tanguylebarzic के शुरुआती काम और नोड_रेडिस पर काम करने वाले सभी लोगों के लिए धन्यवाद!

नमस्ते,

मैं इस पर बहुत सारी चर्चाओं से चूक गया... आंतरिक रूप से, हमने प्रहरी क्लाइंट दिशानिर्देशों (http://redis.io/topics/sentinel-clients) के बहुत करीब एक दृष्टिकोण पर स्विच किया है, जो इसे आसान IMO बनाता है। यह @jamessharp ने जो प्रस्तावित किया है, https://gist.github.com/tanguylebarzic/5521378
यह कुछ महीनों से बिना किसी समस्या के चल रहा है। हालांकि, इसे सुचारू रूप से काम करने के लिए index.js में कुछ बदलावों की आवश्यकता है। उदाहरण के लिए, यदि किसी कारण से मास्टर को प्रहरी में डाउनग्रेड किया जाता है, तो रेडिस एक उत्तर त्रुटि के साथ उत्तर देगा (पढ़ने के लिए आप केवल पढ़ने वाले दास के खिलाफ नहीं लिख सकते हैं।) जो वर्तमान में रेडिस-क्लाइंट से त्रुटि के रूप में उत्सर्जित नहीं होता है, इस प्रकार कनेक्शन के लिए अद्यतन को पकड़ना और ट्रिगर करना असंभव बना देता है। @Newleafdigital द्वारा पुल अनुरोध निश्चित रूप से मदद करते हैं।

@tanguylebarzic , आपका नमूना वास्तव में अच्छा लग रहा है। क्या आप अधिक विवरण दे सकते हैं कि आपके द्वारा उल्लिखित index.js में वास्तव में कौन से परिवर्तन किए जाने चाहिए।

सहायता के लिए धन्यवाद।

एफवाईआई - मैंने इस समस्या (हमारे रेडिस सेंटिनल क्लाइंट) के समाधान के बारे में हमारे देव ब्लॉग, http://docusigndev.github.io/articles/redis-sentinel-client-nodejs/ पर एक ब्लॉग पोस्ट लिखा था। मुझे सबसे अच्छा तरीका जानने के लिए इस विषय पर बातचीत देखना अच्छा लगेगा!

नमस्ते @benbuckman क्या आपने #504 देखा है - मुझे उम्मीद है कि इस पुस्तकालय के साथ एक प्रहरी प्रबंधक (और क्लस्टर) के सही एकीकरण को सक्षम करेगा। उस संबंध में आपके इनपुट और मदद का बहुत स्वागत है!

यहाँ कोई प्रगति?

मैं @benbuckman के मॉड्यूल का उपयोग कर रहा हूं, लेकिन उससे सहमत हूं कि मैं यहां सर्वोत्तम दृष्टिकोण पर और अधिक कॉन्वो और कार्रवाई देखना चाहता हूं।

प्रहरी समर्थन के बारे में अब क्या? क्या कोई प्रगति हुई है?

मेरे लिए भी क्षमा करें... इस पर क्या प्रगति है? ऐसा लगता है कि अभी इस मॉड्यूल पर कोई सक्रिय विकास नहीं हुआ है।

नोड_रेडिस +1 . में मूल प्रहरी समर्थन

@ब्लेन्समिथ वॉट

@blainsmith क्या आप हमें

उफ़। मैं इस पर अपनी डिब्बाबंद प्रतिक्रिया में पेस्ट करना भूल गया। मैं वास्तव में पुराने मुद्दों से गुजर रहा था और सफाई कर रहा था। उसके लिए माफ़ करना। मैं इसे फिर से खोलूंगा और तदनुसार टैग करूंगा!

@blainsmith आह, मैं देखता हूँ। अद्यतन के लिए धन्यवाद। :)

क्या सेंटिनल पर कोई खबर है? क्या आप किसी ड्रॉप-इन प्रतिस्थापन के बारे में जानते हैं जो सेंटिनल का समर्थन करता है?

_संपादित करें: प्रहरी_ का परीक्षण करने के बाद इसके बजाय RedisLabs का उपयोग करने का निर्णय लिया

कोई खबर? :(

क्या कोई संभावना है कि सबसे लोकप्रिय रेडिस क्लाइंट को 8 वर्षों के बाद किसी भी भविष्य में सबसे अधिक वांछित सुविधा (विशेष रूप से बादलों के लिए) मिल जाएगी? 🤔

या कोई बता सकता है कि ऐसा करने में क्या समस्या है? 🧐

मैंने ioredis पर स्विच किया .. यह प्रतिस्थापन में एक प्रकार की गिरावट है