डिस्ट्रिब्यूटेड लॉकिंग को कैसे इम्प्लीमेंट करें (2016)

 (martin.kleppmann.com)
4 पॉइंट द्वारा GN⁺ 2024-10-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें

डिस्ट्रिब्यूटेड लॉक इम्प्लीमेंट करना

  • Redis वेबसाइट पर Redlock algorithm मिला, जो दावा करता है कि यह Redis के ऊपर fault-tolerant distributed locking इम्प्लीमेंट करता है.
  • Redlock के कई स्वतंत्र implementations पहले से मौजूद हैं, और संभव है कि कुछ लोग इस algorithm पर निर्भर हों, इसलिए लेखक ने अपने नोट्स साझा करने का फैसला किया.
  • Redis अस्थायी और तेजी से बदलने वाले data को servers के बीच साझा करने में उपयोगी है, लेकिन इसे strong consistency और durability की आवश्यकता वाले data management क्षेत्र तक बढ़ाना चिंताजनक है.

लॉक का उद्देश्य

  • लॉक का काम यह सुनिश्चित करना है कि कई nodes में से केवल एक ही कोई खास काम करे.
  • अगर लॉक का उपयोग efficiency के लिए किया जा रहा है, तो एक single Redis instance का उपयोग करना बेहतर हो सकता है.
  • अगर लॉक का उपयोग correctness के लिए किया जा रहा है, तो Redlock उपयुक्त नहीं है.

संसाधनों को लॉक से सुरक्षित करना

  • डिस्ट्रिब्यूटेड सिस्टम में लॉक, multithreaded application के mutex से अलग होता है.
  • यह इस बात को रोकता है कि जब एक client किसी file को पढ़कर, संशोधित करके, फिर से लिख रहा हो, तब कोई दूसरा client वही काम न कर सके.

fencing के जरिए सुरक्षित लॉक इम्प्लीमेंट करना

  • fencing token का उपयोग करके और उसे write request में शामिल करके सुरक्षित लॉक इम्प्लीमेंट किया जा सकता है.
  • Redlock में fencing token जनरेट करने की क्षमता नहीं है, इसलिए यह सुरक्षित नहीं है.

consensus के लिए समय का उपयोग

  • asynchronous model में algorithms के विपरीत, Redlock समय के बारे में बहुत सी धारणाओं पर निर्भर करता है.
  • अगर system clock असामान्य तरीके से काम करे, तो key expiration अपेक्षा से तेज या धीमा हो सकता है.

Redlock की समय-संबंधी धारणाओं को तोड़ना

  • Redlock synchronous system model मानता है, और यह केवल तभी सही तरह काम करता है जब network delay, process pause, और clock error सीमित हों.
  • GitHub की 90-second packet delay घटना जैसे मामले Redlock की safety को खतरे में डाल सकते हैं.

निष्कर्ष

  • Redlock, efficiency-optimized locks के लिए अनावश्यक रूप से भारी है, और correctness की आवश्यकता वाले मामलों के लिए पर्याप्त रूप से सुरक्षित नहीं है.
  • अगर correctness के लिए लॉक चाहिए, तो ZooKeeper जैसे उचित consensus system का उपयोग करना बेहतर है.

GN⁺ का सार

  • Redlock algorithm डिस्ट्रिब्यूटेड सिस्टम में लॉक इम्प्लीमेंटेशन पर एक महत्वपूर्ण चर्चा प्रस्तुत करता है.
  • यह लेख डिस्ट्रिब्यूटेड सिस्टम में समय-संबंधी धारणाओं और safety समस्याओं को उजागर करता है, और सही लॉक इम्प्लीमेंटेशन के महत्व को समझाता है.
  • ZooKeeper जैसे वैकल्पिक systems की सिफारिश की गई है, और यह डिस्ट्रिब्यूटेड सिस्टम की जटिलता को समझने में मदद करता है.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-21
Hacker News टिप्पणियाँ
  • Temporal का उपयोग करके distributed lock लागू करने का अनुभव है, और यह अब तक अच्छी तरह काम कर रहा है। Temporal की सुविधाओं का उपयोग करने से distributed lock का implementation सरल हो जाता है
  • ब्लॉग टिप्पणियों में यह राय दी गई कि एल्गोरिदम का एक महत्वपूर्ण बिंदु छूट गया था, और इस कारण यह बताया गया कि इसकी अस्वीकृति एल्गोरिदम की एक कमजोर कड़ी पर आधारित है
  • आधुनिक कंप्यूटर और API का उपयोग करने पर लगभग समय-आधारित प्रतीक्षा संभव है, GC pause सीमित होते हैं और monotonic clock काम करती है। यह एक स्वीकार्य मान्यता है
  • auto-release mechanism की आलोचना करना और एल्गोरिदम के लक्ष्य तथा system model की आलोचना करना दो अलग बातें हैं
  • Redlock का विभिन्न use cases में सफलतापूर्वक उपयोग हुआ है, और timeout को सही तरह सेट किया जाए तो race condition पैदा करना कठिन होता है। बहुत छोटा timeout सेट करना design error है
  • low-level और algorithm संबंधी ज्ञान को अपडेट कर रहा हूँ, और मज़े के लिए कुछ बनाना चाहता हूँ, लेकिन अधिकांश सामग्री या तो toy-level की है या बहुत जटिल है
  • PostgreSQL का उपयोग करके distributed lock लागू करता हूँ, transaction शुरू करता हूँ, advisory lock प्राप्त करता हूँ, और transaction के release होने तक lock बनाए रखता हूँ
  • यह एहसास हुआ कि database connection की स्थिति की जाँच नहीं की थी, और यदि काम database-संबंधित नहीं था तो lock खो गया हो सकता है
  • Deno और Deno KV का उपयोग करके distributed lock लागू किया, और यह FoundationDB पर आधारित है
  • Redis पर विचार किया था, लेकिन PostgreSQL का उपयोग करके request को SET operation में बदलकर correctness समस्या हल की
  • कई engineers correctness समस्याओं को महत्वपूर्ण नहीं मानते, जबकि ऐसे edge cases मौजूद हैं जहाँ message खो सकते हैं या क्रम गलत हो सकता है
  • lock पर timeout सेट करना एक अच्छा विचार है, और यदि client crash हो जाए तो OS या supervisor lock को release कर देता है
  • जहाँ lock की आवश्यकता नहीं है, वहाँ version token का उपयोग करके data integrity बनाए रखी जा सकती है। UUID जैसी unique value का उपयोग किया जा सकता है