बुकस्लीव/रेडिस में पबसुब कैसे काम करता है?

1:आपके उदाहरण में केवल एक चैनल है (Test ); एक चैनल सिर्फ एक विशेष पब/उप एक्सचेंज के लिए इस्तेमाल किया जाने वाला नाम है। हालांकि, 2 कनेक्शन . का उपयोग करना आवश्यक है रेडिस एपीआई कैसे काम करता है, इसकी बारीकियों के कारण। एक कनेक्शन जिसमें कोई भी . है सदस्यताएँ इसके अलावा और कुछ नहीं कर सकतीं:

• संदेश सुनें
• अपने स्वयं के सब्सक्रिप्शन प्रबंधित करें (subscribe , psubscribe , unsubscribe , psubscribe )

हालांकि, मैं यह नहीं समझता:

private static Dictionary<string, RedisSubscriberConnection>

आपको एक से अधिक सब्स्क्राइबर कनेक्शन की आवश्यकता नहीं होनी चाहिए, जब तक कि आप अपने लिए किसी विशिष्ट चीज़ की पूर्ति नहीं कर रहे हों। एक एकल ग्राहक कनेक्शन सदस्यता की मनमानी संख्या को संभाल सकता है। client list पर एक त्वरित जांच करें मेरे एक सर्वर पर, और मेरा 23,002 सब्सक्रिप्शन (लेखन के समय) के साथ एक कनेक्शन है। जिसे शायद कम किया जा सकता है, लेकिन:यह काम करता है।

2:पैटर्न सदस्यता वाइल्डकार्ड का समर्थन करती है; इसलिए /topic/1 . की सदस्यता लेने के बजाय , /topic/2/ आदि आप /topic/* . की सदस्यता ले सकते हैं . वास्तविक . का नाम publish . द्वारा उपयोग किया जाने वाला चैनल कॉलबैक हस्ताक्षर के हिस्से के रूप में रिसीवर को प्रदान किया जाता है।

या तो काम कर सकते हैं। यह ध्यान दिया जाना चाहिए कि publish . का प्रदर्शन अद्वितीय सदस्यताओं की कुल संख्या से प्रभावित होता है - लेकिन स्पष्ट रूप से यह अभी भी मूर्खतापूर्ण तेज़ है (जैसा कि:0ms में) भले ही आपके पास subscribe का उपयोग करके दसियों हज़ार से अधिक सब्सक्राइब किए गए चैनल हों बजाय psubscribe ।

लेकिन publish . से

समय जटिलता:ओ (एन + एम) जहां एन प्राप्त करने वाले चैनल की सदस्यता लेने वाले ग्राहकों की संख्या है और एम सब्सक्राइब किए गए पैटर्न की कुल संख्या है (किसी भी ग्राहक द्वारा)।

मैं पब/उप के रेडिस दस्तावेज़ पढ़ने की सलाह देता हूं।

अनुवर्ती प्रश्नों के लिए संपादित करें:

ए) मुझे लगता है कि मुझे समकालिक रूप से "प्रकाशित" करना होगा (परिणाम या प्रतीक्षा () का उपयोग करके) यदि मैं गारंटी देना चाहता हूं कि आइटम प्राप्त करते समय उसी प्रकाशक से आइटम भेजने का क्रम संरक्षित है, सही है?

इससे कोई फर्क नहीं पड़ेगा; चूंकि आप Result . का उल्लेख करते हैं / Wait() , मुझे लगता है कि आप BookSleeve के बारे में बात कर रहे हैं - जिस स्थिति में मल्टीप्लेक्सर पहले से ही कमांड ऑर्डर को सुरक्षित रखता है। रेडिस स्वयं सिंगल थ्रेडेड है, और हमेशा एक ही कनेक्शन पर कमांड को प्रोसेस करेगा। हालाँकि:सब्सक्राइबर पर कॉलबैक को एसिंक्रोनस रूप से निष्पादित किया जा सकता है और एक वर्कर थ्रेड को (अलग से) सौंपा जा सकता है। मैं वर्तमान में जांच कर रहा हूं कि क्या मैं इसे RedisSubscriberConnection से इन-ऑर्डर करने के लिए बाध्य कर सकता हूं ।

अपडेट:1.3.22 से आप CompletionMode . सेट कर सकते हैं PreserveOrder . के लिए - तब सभी कॉलबैक समवर्ती के बजाय क्रमिक रूप से पूरे किए जाएंगे।

बी) आपके सुझावों के अनुसार समायोजन करने के बाद पेलोड के आकार की परवाह किए बिना कुछ आइटम प्रकाशित करते समय मुझे एक अच्छा प्रदर्शन मिलता है। हालांकि, एक ही प्रकाशक द्वारा 100,000 या अधिक आइटम भेजते समय प्रदर्शन तेजी से गिर जाता है (मेरी मशीन से भेजने के लिए केवल 7-8 सेकंड तक)।

सबसे पहले, वह समय उच्च लगता है - स्थानीय रूप से मुझे परीक्षण मिलता है (100,000 प्रकाशनों के लिए, उन सभी के लिए प्रतिक्रिया की प्रतीक्षा सहित) 1766ms (स्थानीय) या 1219ms (रिमोट) (जो कि प्रति-सहज लग सकता है, लेकिन मेरा "स्थानीय" है ' t रेडिस का एक ही संस्करण चला रहा है; मेरा "रिमोट" Centos पर 2.6.12 है; मेरा "स्थानीय" विंडोज़ पर 2.6.8-pre2 है)।

मैं आपके वास्तविक सर्वर को तेज़ या नेटवर्क को तेज़ नहीं कर सकता, लेकिन:यदि यह पैकेट विखंडन है, तो मैंने (सिर्फ आपके लिए) एक SuspendFlush() जोड़ा है। / ResumeFlush() जोड़ा। यह उत्सुक-फ्लशिंग को अक्षम करता है (अर्थात जब प्रेषण-कतार खाली होती है; अन्य प्रकार की फ्लशिंग अभी भी होती है); आपको यह मदद मिल सकती है:

conn.SuspendFlush();
try {
    // start lots of operations...
} finally {
    conn.ResumeFlush();
}

ध्यान दें कि आपको Wait नहीं करना चाहिए जब तक आप फिर से शुरू नहीं कर लेते, क्योंकि जब तक आप ResumeFlush() . पर कॉल नहीं करते हैं सेंड-बफर में अभी भी कुछ ऑपरेशन हो सकते हैं। उस सब के साथ, मुझे (100,000 ऑपरेशनों के लिए) मिलता है:

local: 1766ms (eager-flush) vs 1554ms (suspend-flush)
remote: 1219ms (eager-flush) vs 796ms (suspend-flush)

जैसा कि आप देख सकते हैं, यह दूरस्थ सर्वर के साथ अधिक मदद करता है, क्योंकि यह नेटवर्क के माध्यम से कम पैकेट डालेगा।

मैं लेन-देन का उपयोग नहीं कर सकता क्योंकि बाद में प्रकाशित होने वाली वस्तुएं सभी एक साथ उपलब्ध नहीं होती हैं। क्या उस ज्ञान को ध्यान में रखते हुए अनुकूलित करने का कोई तरीका है?

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

क्या आप एक सामान्य RedisConnection और एक RedisSubscriberConnection या किसी अन्य कॉन्फ़िगरेशन की अनुशंसा करते हैं ताकि ऐसा रैपर वांछित कार्य कर सके?

जब तक आप ब्लॉकिंग ऑपरेशन नहीं कर रहे हैं (blpop , brpop , brpoplpush आदि), या तार के नीचे बड़े आकार के बीएलओबी डालने (संभावित रूप से अन्य परिचालनों में देरी हो रही है), फिर प्रत्येक प्रकार का एक कनेक्शन आमतौर पर बहुत अच्छी तरह से काम करता है। लेकिन आपकी सटीक उपयोग आवश्यकताओं के आधार पर वाईएमएमवी।