रेडिस लेनदेन और लंबे समय तक चलने वाली लुआ स्क्रिप्ट

Redis लेनदेन को संभालने के लिए दो तंत्र प्रदान करता है - MULTI/EXEC आधारित लेनदेन और Lua स्क्रिप्ट मूल्यांकन। रेडिस लुआ स्क्रिप्टिंग अनुशंसित दृष्टिकोण है और उपयोग में काफी लोकप्रिय है।

हमारे Redis™ ग्राहक जिनके पास Lua स्क्रिप्ट तैनात हैं, वे अक्सर इस त्रुटि की रिपोर्ट करते हैं - "BUSY Redis एक स्क्रिप्ट चलाने में व्यस्त है। आप केवल स्क्रिप्ट किल या शटडाउन नोसेव को कॉल कर सकते हैं " इस पोस्ट में, हम स्क्रिप्ट की रेडिस ट्रांजेक्शनल प्रॉपर्टी की व्याख्या करेंगे, यह त्रुटि क्या है, और हमें सेंटिनल-प्रबंधित सिस्टम पर इसके बारे में अतिरिक्त सावधान रहना चाहिए जो विफल हो सकता है।

Redis Lua Scripts की लेन-देन संबंधी प्रकृति

Redis "लेन-देन" वास्तव में पारंपरिक रूप से समझे जाने वाले लेन-देन नहीं हैं - त्रुटियों के मामले में, स्क्रिप्ट द्वारा किए गए लेखन का कोई रोलबैक नहीं है।

Redis लिपियों की "परमाणुता" की गारंटी निम्नलिखित तरीके से दी जाती है:

• एक बार स्क्रिप्ट का निष्पादन शुरू हो जाने के बाद, अन्य सभी कमांड/स्क्रिप्ट स्क्रिप्ट के पूरा होने तक ब्लॉक कर दी जाती हैं। इसलिए, अन्य क्लाइंट या तो स्क्रिप्ट द्वारा किए गए परिवर्तनों को देखते हैं या वे नहीं देखते हैं। ऐसा इसलिए है क्योंकि वे केवल स्क्रिप्ट से पहले या स्क्रिप्ट के बाद ही निष्पादित कर सकते हैं।
• हालांकि, रेडिस रोलबैक नहीं करता है, इसलिए स्क्रिप्ट में किसी त्रुटि पर, स्क्रिप्ट द्वारा पहले से किए गए किसी भी परिवर्तन को बरकरार रखा जाएगा और भविष्य के कमांड/स्क्रिप्ट में वे आंशिक परिवर्तन दिखाई देंगे।
• चूंकि स्क्रिप्ट निष्पादित होने के दौरान अन्य सभी क्लाइंट अवरुद्ध हैं, इसलिए यह महत्वपूर्ण है कि स्क्रिप्ट अच्छी तरह से व्यवहार की जाए और समय पर समाप्त हो जाए।

‘लुआ-टाइम-लिमिट’ मान

यह अत्यधिक अनुशंसा की जाती है कि स्क्रिप्ट एक समय सीमा के भीतर पूरी हो जाए। Redis इसे कमजोर तरीके में लागू करता है 'लुआ-टाइम-लिमिट' मान के साथ। यह अधिकतम अनुमत समय (एमएस में) है कि स्क्रिप्ट को चलाने की अनुमति है। डिफ़ॉल्ट मान 5 सेकंड है। सीपीयू-बाध्य गतिविधि के लिए यह वास्तव में एक लंबा समय है (स्क्रिप्ट की सीमित पहुंच है और डिस्क तक पहुंचने वाले आदेश नहीं चला सकते हैं)।

हालांकि, इस समय के बाद स्क्रिप्ट निष्पादित होने पर समाप्त नहीं होती है। Redis क्लाइंट कमांड को फिर से स्वीकार करना शुरू कर देता है, लेकिन एक BUSY त्रुटि के साथ उनका जवाब देता है।

यदि आपको इस समय स्क्रिप्ट को समाप्त करना है, तो दो विकल्प उपलब्ध हैं:

• स्क्रिप्ट किल कमांड का उपयोग उस स्क्रिप्ट को रोकने के लिए किया जा सकता है जिसने अभी तक कोई लेखन नहीं किया है।
• यदि स्क्रिप्ट पहले ही सर्वर को लिख चुकी है और अभी भी समाप्त होनी चाहिए, तो SHUTDOWN NOSAVE का उपयोग करें सर्वर को पूरी तरह से बंद करने के लिए।

आमतौर पर बेहतर होता है कि स्क्रिप्ट के संचालन के पूरा होने की प्रतीक्षा करें। स्क्रिप्ट निष्पादन और संबंधित व्यवहार को समाप्त करने के तरीकों की पूरी जानकारी दस्तावेज़ीकरण में उपलब्ध है।

प्रहरी-निगरानी वाले उच्च उपलब्धता सिस्टम पर व्यवहार

प्रहरी-प्रबंधित उच्च उपलब्धता सिस्टम इसमें एक नई शिकन जोड़ते हैं। वास्तव में, यह चर्चा किसी भी उच्च उपलब्धता प्रणाली पर लागू होती है जो स्वास्थ्य के लिए रेडिस सर्वर के मतदान पर निर्भर करती है:

• लंबे समय तक चलने वाली स्क्रिप्ट शुरू में क्लाइंट कमांड को ब्लॉक कर देंगी। बाद में जब 'लुआ-समय-सीमा' बीत गई, तो सर्वर व्यस्त त्रुटियों के साथ प्रतिक्रिया देना शुरू कर देगा।
• प्रहरी ऐसे नोड को अनुपलब्ध मानेंगे, और यदि यह सेंटिनल्स पर कॉन्फ़िगर किए गए डाउन-आफ्टर-मिलीसेकंड मान से आगे बना रहता है, तो वे नोड को डाउन होने का निर्धारण करेंगे।
• यदि ऐसा नोड मास्टर है, तो एक विफलता शुरू की जाएगी। एक प्रतिकृति नोड को बढ़ावा मिल सकता है और ग्राहकों से नए कनेक्शन स्वीकार करना शुरू कर सकता है।
• इस बीच, पुराने मास्टर अंततः स्क्रिप्ट का निष्पादन पूरा कर लेंगे और ऑनलाइन वापस आ जाएंगे। हालांकि, सेंटिनल अंततः इसे एक प्रतिकृति के रूप में पुन:कॉन्फ़िगर करेगा और यह नए मास्टर के साथ समन्वयित करना शुरू कर देगा। स्क्रिप्ट द्वारा लिखा गया कोई भी डेटा नष्ट हो जाएगा।

प्रदर्शन

हमने इस विफलता व्यवहार को प्रदर्शित करने के लिए एक संवेदनशील उच्च उपलब्धता प्रणाली स्थापित की है। सेटअप में 2 Redis सर्वर हैं जो एक मास्टर/प्रतिकृति कॉन्फ़िगरेशन में चल रहे हैं जिसकी निगरानी 3-सेंटिनल कोरम द्वारा की जा रही है।

lua-time-limit value 500 ms पर सेट की गई थी ताकि अगर स्क्रिप्ट 500 ms से अधिक समय तक चलती है तो यह क्लाइंट को त्रुटियों के साथ प्रतिक्रिया देना शुरू कर देता है। प्रहरी पर डाउन-आफ्टर-मिलीसेकंड का मान 5 सेकंड पर सेट किया जाता है ताकि त्रुटियों की रिपोर्ट करने वाला नोड 5 सेकंड के बाद नीचे चिह्नित हो जाए।

हम मास्टर पर निम्नलिखित लुआ स्क्रिप्ट निष्पादित करते हैं:

local i = 0
while (true)
do
local key = "Key-" .. i
local value = "Value-" .. i
redis.call('set', key, value)
i = i + 1
redis.call('time')
end

यह रेडिस मास्टर में प्रविष्टियां लिखता रहता है। हम व्यवहार का निरीक्षण करने के लिए प्रहरी में से एक पर घटनाओं की सदस्यता लेते हैं।

स्क्रिप्ट मास्टर पर शुरू की गई है:

$ redis-cli -a  --eval test.lua
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.

यहाँ गतिविधियों का एक छोटा क्रम दिया गया है जैसा कि सेंटिनल पर देखा गया है:

3) "+vote-for-leader"
4) "9096772621089bb885eaf7304a011d9f46c5689f 1"
1) "pmessage"
2) "*"
3) "+sdown" <<< master marked DOWN
4) "master test 172.31.2.48 6379"
1) "pmessage"
2) "*"
3) "+odown"
4) "master test 172.31.2.48 6379 #quorum 3/2"
1) "pmessage"
2) "*"
3) "-role-change" << role change initiated
4) "slave 172.31.28.197:6379 172.31.28.197 6379 @ test 172.31.2.48 6379 new reported role is master"
1) "pmessage"
2) "*"
3) "+config-update-from"
4) "sentinel 9096772621089bb885eaf7304a011d9f46c5689f 172.31.2.48 26379 @ test 172.31.2.48 6379"
1) "pmessage"
2) "*"
3) "+switch-master"
4) "test 172.31.2.48 6379 172.31.28.197 6379"

बाद में, जब पुराने मास्टर को ऑनलाइन लाया जाता है, तो उसे एक प्रतिरूप में बदल दिया जाता है:

3) "-role-change"
4) "slave 172.31.2.48:6379 172.31.2.48 6379 @ test 172.31.28.197 6379 new reported role is master"
1) "pmessage"
2) "*"
3) "-sdown"
4) "slave 172.31.2.48:6379 172.31.2.48 6379 @ test 172.31.28.197 6379"
1) "pmessage"
2) "*"
3) "+role-change"
4) "slave 172.31.2.48:6379 172.31.2.48 6379 @ test 172.31.28.197 6379 new reported role is slave"

पुराने मास्टर को स्क्रिप्ट के माध्यम से लिखा गया सारा डेटा नष्ट हो जाता है।

सिफारिशें

• अपनी लंबे समय से चल रही स्क्रिप्ट को प्रोडक्शन में लगाने से पहले आपको उनकी विशेषताओं के बारे में पहले से पता होना चाहिए।
• यदि आपकी स्क्रिप्ट नियमित रूप से लुआ-समय-सीमा का उल्लंघन करती है, तो आपको संभावित अनुकूलन के लिए स्क्रिप्ट की पूरी तरह से समीक्षा करनी चाहिए। आप इसे टुकड़ों में भी विभाजित कर सकते हैं जो स्वीकार्य अवधियों में पूर्ण होते हैं।
• यदि आपको ऐसी स्क्रिप्ट चलानी हैं जो लुआ-समय-सीमा का उल्लंघन करती हैं, तो इन स्क्रिप्ट को उस अवधि के दौरान शेड्यूल करने पर विचार करें जब अन्य क्लाइंट गतिविधि कम हो।
• लुआ-समय-सीमा का मान भी बढ़ाया जा सकता है। यह एक स्वीकार्य समाधान होगा यदि अन्य क्लाइंट एप्लिकेशन जो स्क्रिप्ट के समानांतर निष्पादित होते हैं, एक व्यस्त त्रुटि के बजाय अत्यधिक विलंबित प्रतिक्रिया प्राप्त करने और बाद में पुनः प्रयास करने को सहन कर सकते हैं।

सेंटिनल-मॉनिटर किए गए उच्च उपलब्धता सिस्टम पर अतिरिक्त विचार:

• यदि स्क्रिप्ट केवल रीड ऑपरेशन कर रही हैं और आपके पास प्रतिकृतियां उपलब्ध हैं, तो आप इन लिपियों को प्रतिकृतियों में स्थानांतरित कर सकते हैं।

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