यहाँ कई प्रश्न हैं।
1) हम लेन-देन में वृद्धि क्यों नहीं कर सकते जो अन्य कमांड द्वारा बाधित नहीं किया जा सकता है?
कृपया पहले ध्यान दें कि रेडिस "लेन-देन" ज्यादातर लोगों के विचार से शास्त्रीय डीबीएमएस में पूरी तरह से अलग हैं।
# Does not work
redis.multi()
current = redis.get('powerlevel')
redis.set('powerlevel', current + 1)
redis.exec()
आपको यह समझने की जरूरत है कि सर्वर-साइड (रेडिस में) पर क्या निष्पादित किया जाता है, और क्लाइंट-साइड (आपकी स्क्रिप्ट में) पर क्या निष्पादित किया जाता है। उपरोक्त कोड में, GET और SET कमांड को रेडिस की ओर से निष्पादित किया जाएगा, लेकिन करंट को असाइनमेंट और करंट + 1 की गणना क्लाइंट साइड पर निष्पादित की जानी चाहिए।
परमाणुता की गारंटी के लिए, एक बहु / EXEC ब्लॉक निष्पादन तक रेडिस कमांड के निष्पादन में देरी करता है। तो क्लाइंट स्मृति में केवल जीईटी और एसईटी कमांड को ढेर करेगा, और उन्हें एक शॉट में और अंत में परमाणु रूप से निष्पादित करेगा। बेशक, जीईटी और वृद्धि के परिणाम के लिए वर्तमान को असाइन करने का प्रयास बहुत पहले होगा। वास्तव में redis.get विधि केवल "QUEUED" स्ट्रिंग लौटाएगी, यह संकेत देने के लिए कि कमांड में देरी हो रही है, और इंक्रीमेंटेशन काम नहीं करेगा।
MULTI/EXEC ब्लॉक में आप केवल उन कमांड का उपयोग कर सकते हैं जिनके पैरामीटर ब्लॉक की शुरुआत से पहले पूरी तरह से ज्ञात हो सकते हैं। आप अधिक जानकारी के लिए दस्तावेज़ीकरण पढ़ना चाह सकते हैं।
2) हमें इसके बजाय पुनरावृति और लेन-देन शुरू होने से पहले तब तक प्रतीक्षा करने की आवश्यकता क्यों है जब तक कि कोई भी मूल्य नहीं बदलता?
यह समवर्ती आशावादी पैटर्न का एक उदाहरण है।
अगर हम कोई WATCH/MULTI/EXEC इस्तेमाल नहीं करते हैं, तो हमारे पास संभावित दौड़ की स्थिति होगी:
# Initial arbitrary value
powerlevel = 10
session A: GET powerlevel -> 10
session B: GET powerlevel -> 10
session A: current = 10 + 1
session B: current = 10 + 1
session A: SET powerlevel 11
session B: SET powerlevel 11
# In the end we have 11 instead of 12 -> wrong
अब एक WATCH/MULTI/EXEC ब्लॉक जोड़ें। WATCH क्लॉज के साथ, MULTI और EXEC के बीच कमांड केवल तभी निष्पादित होते हैं जब मान नहीं बदला हो।
# Initial arbitrary value
powerlevel = 10
session A: WATCH powerlevel
session B: WATCH powerlevel
session A: GET powerlevel -> 10
session B: GET powerlevel -> 10
session A: current = 10 + 1
session B: current = 10 + 1
session A: MULTI
session B: MULTI
session A: SET powerlevel 11 -> QUEUED
session B: SET powerlevel 11 -> QUEUED
session A: EXEC -> success! powerlevel is now 11
session B: EXEC -> failure, because powerlevel has changed and was watched
# In the end, we have 11, and session B knows it has to attempt the transaction again
# Hopefully, it will work fine this time.
इसलिए आपको तब तक प्रतीक्षा करने की आवश्यकता नहीं है जब तक कि कोई भी मान नहीं बदलता है, बल्कि ऑपरेशन को बार-बार करने का प्रयास करने के लिए जब तक कि रेडिस सुनिश्चित नहीं हो जाता है कि मान सुसंगत हैं और यह संकेत देता है कि यह सफल है।
ज्यादातर मामलों में, यदि "लेन-देन" काफी तेज हैं और विवाद होने की संभावना कम है, तो अपडेट बहुत कुशल होते हैं। अब, यदि विवाद है, तो कुछ "लेन-देन" (पुनरावृत्ति और पुन:प्रयास के कारण) के लिए कुछ अतिरिक्त संचालन करना होगा। लेकिन डेटा हमेशा सुसंगत रहेगा और किसी लॉकिंग की आवश्यकता नहीं है।
