पाठ 16 / 32
लीडर इलेक्शन और आइडेम्पोटेंसी
Leader election और Raft consensus समझें, और idempotency keys से retries को सुरक्षित बनाएँ।
लीडर की ज़रूरत क्यों
कुछ निर्णयों (कौन राइट स्वीकार करे, कौन काम सौंपे) के लिए एक समय में बिल्कुल एक नोड ज़िम्मेदार होना चाहिए। लीडर इलेक्शन क्लस्टर को उस नोड पर सहमत होने देता है और पता लगाता है कि उसे कब बदलना है।
Raft, संक्षेप में
Raft एक कंसेंसस एल्गोरिद्म है जहाँ नोड्स यादृच्छिक टाइमआउट का उपयोग कर लीडर के लिए वोट करते हैं; सबसे अधिक वोट वाला उम्मीदवार एक टर्म जीतता है। लीडर फ़ॉलोअर्स को एक लॉग रेप्लिकेट करता है, और कोई एंट्री तभी कमिटेड मानी जाती है जब बहुमत के पास हो — यह नोड विफलताओं के किसी भी अल्पमत को झेल लेता है।
आइडेम्पोटेंसी बचाती है
नेटवर्क टाइमआउट नहीं बताता कि रिक्वेस्ट पहुँची या नहीं। यदि रिट्राई और डुप्लिकेट डिलीवरी अपरिहार्य हैं, तो ऑपरेशन को आइडेम्पोटेंट बनाएँ: एक क्लाइंट-जनरेटेड idempotency key सर्वर को एक ही तार्किक रिक्वेस्ट की पुनरावृत्ति पहचानने और सुरक्षित रूप से अनदेखा करने देती है।
त्वरित जाँच: Raft में, लॉग एंट्री कब कमिटेड मानी जाती है?
- जैसे ही लीडर इसे लिखता है
- एक बार जब हर नोड ने इसे रेप्लिकेट कर लिया हो
- केवल जब कोई client उसे पढ़े
- एक बार जब बहुमत नोड्स ने इसे रेप्लिकेट कर लिया हो
Answer
एक बार जब बहुमत नोड्स ने इसे रेप्लिकेट कर लिया हो — बहुमत (कोरम) कमिटमेंट Raft को सही बने रहते हुए नोड विफलताओं के अल्पमत को सहने देता है।