यदि रेडिस सिंगल थ्रेडेड है, तो लॉकिंग मैकेनिज्म की बिल्कुल आवश्यकता क्यों है।
रेडिस वास्तव में (ज्यादातर) सिंगल-थ्रेडेड है लेकिन लॉकिंग की आवश्यकता होती है जब कई क्लाइंट आसन्न अस्थायी निकटता पर अलग-अलग काम करने का प्रयास करते हैं। RiA में जिस लॉकिंग की चर्चा की गई है, वह ठीक उसी के बारे में है - यह सुनिश्चित करना कि केवल एक क्लाइंट/थ्रेड एक विशिष्ट कार्य करता है, या यह सुनिश्चित करता है कि अपडेट गड़बड़ा न जाए।
यहां एक उदाहरण दिया गया है कि रेडिस की सिंगल-थ्रेडेडनेस के बावजूद आपको लॉकिंग की आवश्यकता क्यों होगी:मान लें कि आपके पास रेडिस में एक मान है, उदाहरण के लिए एक संख्या जिसे foo
नामक कुंजी के तहत संग्रहीत किया जाता है। . आपके ऐप का कोड उस नंबर को पढ़ता है (GET foo
), कुछ करता है (अर्थात 1 जोड़ता है) और इसे वापस लिखता है (SET
) जब आप अपना कोड एक ही थ्रेड में चलाते हैं, तो यह इस तरह दिखेगा:
App Redis
|---- GET foo ---->|
|<------ 1 --------|
| |
| thinking... |
| |
|--- SET foo 2 --->|
|<----- OK --------|
अब देखते हैं कि क्या होता है जब दो ऐप क्लाइंट ऐसा करने का प्रयास करते हैं:
App 1 Redis App 2
|---- GET foo ---->| |
|<------ 1 --------|<--- GET foo -----|
| |------- 1 ------->|
| thinking... | |
| | thinking...|
|--- SET foo 2 --->| |
|<----- OK --------|<--- SET foo 2 ---|
| |------ OK ------->|
यहां आप तुरंत देख सकते हैं कि सर्वर (ज्यादातर) सिंगल थ्रेडेड होने के बावजूद बिना लॉक किए क्या हुआ - 3 के बजाय, foo
का मान 2 है। जैसे-जैसे आप अधिक थ्रेड/क्लाइंट/ऐप्स जोड़ते हैं, चीजें बहुत बुरी तरह से गलत हो सकती हैं, जब कई लेखक समन्वय के बिना डेटा को संशोधित करने का प्रयास करते हैं (यानी लॉकिंग)।
आशावादी लॉकिंग ऐसा करने का एक तरीका है, जिसे Redis WATCH
के माध्यम से बिल्ट-इन प्रदान करता है। तंत्र। कभी-कभी, हालांकि, आशावाद - इसकी आसान और खुशहाल प्रकृति के बावजूद - सही समाधान नहीं है, इसलिए आपको दौड़ की स्थिति को रोकने के लिए बेहतर/उन्नत/विभिन्न तंत्रों को लागू करने की आवश्यकता होगी। इस तरह के ताले, यकीनन, रेडिस के बाहर भी लागू किए जा सकते हैं, लेकिन अगर आप पहले से ही इसका उपयोग कर रहे हैं तो इसमें अपने ताले को भी प्रबंधित करना समझ में आता है।