वर्तमान में परीक्षण चल रहा है: पूरा होने पर GitHub कोड खोला जाएगा।
Ticketing
दस्तावेज़
हिन्दी

प्रोटोकॉल (क्लस्टर) — सर्वर ↔ सर्वर ​

पीयर RPC प्रोटोकॉल, जो केवल क्लस्टर मोड में उपयोग होता है। नोड Raft सर्वसम्मति के ज़रिए एक ही लॉक स्थिति साझा करते हैं — हर लॉक-स्थिति परिवर्तन (अधिग्रहण, रिलीज़, समाप्ति) तभी लागू होता है जब लीडर का प्रस्ताव → बहुमत प्रतिकृति → कमिट पूरा हो चुका हो, इसलिए विभाजन या फ़ेलओवर के दौरान भी परस्पर बहिष्करण बना रहता है। वैचारिक व्याख्या के लिए यह कैसे काम करता है देखें।

प्रवाह — एक अधिग्रहण के कमिट होने तक ​

क्लाइंट
लीडर
फॉलोवर 1
फॉलोवर 2
A · अधिग्रहण (key)
AppendEntries (Grant)
AppendEntries (Grant)
OK
बहुमत तक पहुँचा → कमिट, हर नोड पर लागू
A · अधिग्रहित (token)
अनुरोधप्रतिक्रियासर्वसम्मति RPC (Raft)

लीडर लॉक कमांड को एक प्रतिकृत कमांड में बदलता है, इसे एक AppendEntries RPC में ले जाता है, और स्वयं सहित एक बहुमत के इसे दर्ज करते ही कमिट कर देता है (3 नोड के साथ, लीडर और फॉलोवर 1 ही पर्याप्त हैं — यह बाकी की प्रतीक्षा नहीं करता)। क्लाइंट प्रतिक्रिया केवल कमिट के बाद ही बाहर जाती है, इसलिए एक बार आपको प्रतिक्रिया मिल जाने पर, वह लॉक बहुमत में दर्ज हो चुका होता है।

पोर्ट और पता नियम ​

  • पीयर RPC एक समर्पित Raft पोर्ट = क्लाइंट पोर्ट + 1000 का उपयोग करता है (जैसे 5225 → 6225)। यह बिना किसी अलग कॉन्फ़िग कुंजी के स्वचालित रूप से निकाला जाता है, और केवल क्लस्टर मोड में सुनता है। आपके फ़ायरवॉल को दोनों पोर्ट खोलने होंगे।
  • कॉन्फ़िगरेशन (cluster_self/cluster_peers) हमेशा क्लाइंट पता रखता है। केवल किसी पीयर को डायल करते समय पोर्ट में +1000 जोड़ा जाता है — क्लाइंट को दिया गया M (स्थानांतरित) रीडायरेक्ट पता हमेशा सामान्य क्लाइंट पता ही होता है।
  • भूमिकाएँ केवल पोर्ट से अलग की जाती हैं — क्लाइंट और पीयर को अलग बताने के लिए प्रोटोकॉल के भीतर कोई चरण नहीं है। कनेक्शन क्रम और प्रमाणीकरण/TLS नियमों के लिए कनेक्शन और प्रमाणीकरण देखें।

विषय-सूची ​

यह भी देखें ​