आपके द्वारा दिए गए उदाहरण और छद्म कोड के साथ, आइए कल्पना करें कि:
recipient.user1प्रति मिनट 60 संदेश मिल रहे हैं- और
perform_task()विधि को निष्पादित करने में 2 सेकंड लगते हैं।
यहां क्या होगा यह स्पष्ट है:एक नए संदेश के आने और इसे संसाधित करने के बीच विलंबता केवल समय के साथ बढ़ेगी, "रीयल-टाइम प्रोसेसिंग" से आगे और आगे बढ़ते हुए।
system throughput = 30 messages/minute
इससे निजात पाने के लिए, हो सकता है कि आप user1 . के लिए एक उपभोक्ता समूह बनाना चाहें . यहां आपके पास समानांतर में चलने वाली 4 अलग-अलग पायथन प्रक्रियाएं हो सकती हैं, सभी 4 user1 के लिए एक ही समूह में शामिल हो गए हैं . अब जब user1 . के लिए कोई संदेश आता है 4 में से कोई एक कार्यकर्ता इसे उठाएगा और perform_task() ।
system throughput = 120 message/minute
आपके उदाहरण में, message.acknowledge() वास्तव में मौजूद नहीं है, क्योंकि आपका स्ट्रीम रीडर अकेला है (XREAD कमांड)।
यदि यह एक समूह था, तो संदेशों की पावती आवश्यक हो जाती है, इस तरह रेडिस जानता है कि समूह के सदस्यों में से एक ने वास्तव में उस संदेश को संभाला है, इसलिए यह "आगे बढ़ सकता है" (यह इस तथ्य को भूल सकता है कि वह संदेश स्वीकृति के लिए लंबित था) . जब आप समूहों का उपयोग कर रहे होते हैं, तो यह सुनिश्चित करने के लिए कि प्रत्येक संदेश उपभोक्ता समूह के किसी एक कार्यकर्ता को एक बार दिया जाता है, सर्वर साइड लॉजिक होता है। (XGROUPREAD कमांड)। जब क्लाइंट समाप्त हो जाता है, तो यह उस संदेश (XACK कमांड) की एक पावती जारी करता है ताकि सर्वर साइड "उपभोक्ता समूह बफर" इसे हटा सके और आगे बढ़ सके।
कल्पना कीजिए कि अगर कोई कार्यकर्ता मर गया और उसने संदेश को कभी स्वीकार नहीं किया। एक उपभोक्ता समूह के साथ, आप इस स्थिति पर नजर रख सकते हैं (XPENDING कमांड का उपयोग करके) और उदाहरण के लिए किसी अन्य उपभोक्ता में उसी संदेश को संसाधित करने का प्रयास करके उन पर कार्रवाई कर सकते हैं।
जब आप समूहों का उपयोग नहीं कर रहे होते हैं, तो रेडिस सर्वर को "आगे बढ़ने" की आवश्यकता नहीं होती है, "पावती" 100% क्लाइंट साइड/बिजनेस लॉजिक बन जाती है।
