Scheduled jobs
वही cron हर instance पर चलती है, और lock यह पक्का करता है कि उनमें से ठीक एक ही काम करे।
कोर डेटाकोऑर्डिनेशन
Distributed Locks
पक्का करें कि एक समय में सिर्फ़ एक worker job चलाए, ऐसे locks के साथ जो अपने आप expire होते हैं और अपना मालिक उन्हें सुरक्षित तरीके से छोड़ता है।
- कमांड acquire करने के लिए
- 1
- कमांड सुरक्षित release के लिए
- 1
- Lua scripts
- 0
कदम 1 में से 5
Worker A lock लेता है
NX उसे तभी लेता है जब कोई पकड़े न हो। PX 30000 से A मर जाए तो वह 30 सेकंड में expire हो जाता है।
उदाहरण सेशनplaying
# Worker A lock लेता है
hotkv> SET lock:billing-run tok-a81f NX PX 30000
OK
असली HotKV कमांड और उदाहरण रिस्पॉन्स के साथ एक एनिमेटेड वॉकथ्रू। किसी भी कदम पर क्लिक करके वहां पहुंचें। कमांड और रिस्पॉन्स अंग्रेज़ी में ही रहते हैं, ठीक वैसे जैसे आप HotKV में टाइप करते और देखते हैं।
समस्या
कई मशीनों पर चलने वाली cron jobs, payment captures और cache rebuilds एक साथ दो बार नहीं चलने चाहिए। बिना expiry वाला lock तब हमेशा के लिए पकड़ा रह जाता है जब उसका मालिक crash हो जाए, और साधारण DEL से lock छोड़ने पर आपका lock expire होने के बाद किसी और का lock delete हो सकता है।
HotKV इसे कैसे संभालता है
NX और PX के साथ SET lock तभी लेता है जब कोई उसे पकड़े न हो, और उसे expiry देता है ताकि crash हुआ मालिक उसे हमेशा न पकड़े रहे। हर मालिक value के रूप में एक random token रखता है। IFEQ के साथ DELEX lock को तभी delete करता है जब उसमें अब भी आपका token हो, और यही वह सुरक्षित release है जिसके लिए पहले Lua script चाहिए होती थी।
कदम दर कदम
क्या होता है, कमांड दर कमांड
- 01
Worker A lock लेता है
NX उसे तभी लेता है जब कोई पकड़े न हो। PX 30000 से A मर जाए तो वह 30 सेकंड में expire हो जाता है।
SET lock:billing-run tok-a81f NX PX 30000 - 02
Worker B को लौटा दिया जाता है
Lock पकड़ा हुआ है, इसलिए B को nil मिलता है और वह इस बार का run छोड़ देता है।
SET lock:billing-run tok-b22c NX PX 30000 - 03
A काम करता है
Billing job सिर्फ़ एक worker चलाता है।
PTTL lock:billing-run - 04
सिर्फ़ अपना lock छोड़ें
DELEX key को तभी delete करता है जब value अब भी A का token हो।
DELEX lock:billing-run IFEQ tok-a81f - 05
गलत token कुछ नहीं करता
अगर A बहुत धीमा रहा होता और अब lock B के पास होता, तो A का release B के lock को छुए बिना छोड़ देता।
DELEX lock:billing-run IFEQ tok-stale
कहां फ़िट बैठता है
असली परिदृश्य
Payments
एक order पर capture और refund के काम एक के बाद एक चलाए जाते हैं, ताकि वे कभी एक-दूसरे पर न चढ़ें।
Cache stampede से बचाव
महँगी cache entry सिर्फ़ एक request दोबारा बनाती है, जबकि बाकी इंतज़ार करती हैं या पुरानी value परोसती हैं।
अंतर्निहित
आपको क्या मिलता है
Expiry के साथ acquire
SET NX PX lock तभी लेता है जब वह खाली हो, timeout के साथ।
SETNXPXसुरक्षित release
DELEX IFEQ तभी delete करता है जब value आपके token से मेल खाए।
DELEXकाम के दौरान बढ़ाएँ
बचा हुआ समय देखें और लंबी jobs के लिए उसे बढ़ा दें।
PTTLPEXPIREDigest से तुलना
बड़ी values के लिए DELEX IFDEQ पूरी value की जगह digest की तुलना करता है।
DIGESTIFDEQआम सवाल
सीधे lock को DEL क्यों न कर दूँ?
अगर आपका lock expire हो गया और किसी दूसरे worker ने उसे ले लिया, तो साधारण DEL उसका lock delete कर देगा। DELEX IFEQ उसे तभी delete करता है जब उसमें अब भी आपका token हो।
Expiry कितनी लंबी होनी चाहिए?
job के सामान्य समय से ज़्यादा। लंबी jobs के लिए, जब तक lock आपके पास है, expiry को समय-समय पर बढ़ाते रहें।
क्या सुरक्षित release के लिए मुझे Lua चाहिए?
नहीं। DELEX तुलना और delete एक ही कमांड में करता है।
संबंधित उपयोग के मामले
इसे अपने वर्कलोड पर आज़माएं
HotKV Redis प्रोटोकॉल बोलता है, इसलिए आप किसी मौजूदा क्लाइंट को इसकी ओर इंगित करके यही कमांड चला सकते हैं।