فی الحال ٹیسٹنگ جاری ہے: مکمل ہونے پر GitHub کوڈ کھول دیا جائے گا۔
Ticketing
دستاویزات
اردو

پروٹوکول — سرور ↔ سرور (کلسٹر) ​

پیئر RPC پروٹوکول، جو صرف کلسٹر موڈ میں استعمال ہوتا ہے۔ نوڈز Raft اتفاقِ رائے کے ذریعے ایک ہی لاک حالت میں شریک ہوتے ہیں — ہر لاک-حالت کی تبدیلی (حصول، اجراء، میعاد ختم) صرف قائد کی تجویز → اکثریت کی نقل → کمٹ کے بعد ہی لاگو ہوتی ہے، اس لیے تقسیم یا failover کے دوران بھی باہمی اخراج برقرار رہتا ہے۔ تصوراتی وضاحت کے لیے یہ کیسے کام کرتا ہے دیکھیں۔

بہاؤ — ایک حصول سے اس کے کمٹ ہونے تک ​

کلائنٹ
قائد
فالوور 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) میں ہمیشہ کلائنٹ پتہ رکھا جاتا ہے۔ صرف کسی پیئر کو dial کرتے وقت پورٹ میں +1000 کیا جاتا ہے — کلائنٹس کو دیا جانے والا M (منتقل شدہ) ری ڈائریکٹ پتہ ہمیشہ سادہ کلائنٹ پتہ ہی ہوتا ہے۔
  • کردار صرف پورٹ سے الگ کیے جاتے ہیں — کلائنٹ اور پیئر میں فرق کرنے کا کوئی in-protocol مرحلہ نہیں ہے۔ کنکشن کی ترتیب اور تصدیق/TLS کے اصولوں کے لیے کنکشن اور تصدیق دیکھیں۔

فہرست ​

مزید دیکھیں ​