البروتوكول — الخادم ↔ الخادم (العنقود) ​

بروتوكول RPC بين الأقران، يُستخدم في وضع العنقود فقط. تشارك العُقد حالة قفل واحدة عبر إجماع Raft — لا يُطبَّق أي تغيير في حالة القفل (حصول، تحرير، انتهاء) إلا بعد اقتراح القائد ← تكرار الأغلبية ← التثبيت، فيستمر الاستبعاد المتبادل حتى أثناء الانقسام أو تبديل الأدوار عند الأعطال. راجع آلية العمل للشرح المفاهيمي.

التدفق — من عملية حصول واحدة حتى تثبيتها ​

يحوّل القائد أمر القفل إلى أمر مُكرَّر، يحمله في RPC من نوع AppendEntries، ويثبّته بمجرد أن تسجله أغلبية تشمله هو نفسه (في عنقود من 3 عُقد، يكفي القائد مع التابع 1 — دون انتظار الباقي). لا تخرج استجابة العميل إلا بعد التثبيت، فبمجرد استلام استجابة، يكون ذلك القفل مكتوبًا لدى الأغلبية.

قواعد المنافذ والعناوين ​

• تستخدم RPC بين الأقران منفذ Raft المخصص = منفذ العميل + 1000 (مثل 5225 ← 6225). يُشتق تلقائيًا دون مفتاح إعداد منفصل، ولا يستمع إلا في وضع العنقود. يجب فتح كلا المنفذين في جدار الحماية.
• يحمل الإعداد (cluster_self/cluster_peers) دائمًا عنوان العميل. الاتصال بقرين فقط يضيف +1000 إلى المنفذ — أما عنوان إعادة التوجيه M (تم النقل) المُعطى للعملاء فهو دائمًا عنوان العميل العادي.
• تُميَّز الأدوار بالمنفذ فقط — لا توجد خطوة داخل البروتوكول للتمييز بين عميل وقرين. راجع الاتصال والمصادقة لترتيب الاتصال وقواعد المصادقة/TLS.

جدول المحتويات ​

• الاتصال بين الخوادم
  • الاتصال والمصادقة
  • بنية الإطار
  • أنواع RPC
  • الأوامر المكرَّرة
  • اللقطة (Snapshot)
• معاملات Raft
• الإعداد (متغيرات البيئة)
• إجراء إعادة التشغيل المتدرّج (Rolling Restart)

انظر أيضًا ​

• شرح مبسّط لانتخاب القائد وتثبيت الأغلبية وسيناريوهات الأعطال — آلية العمل
• قاعدة عثور العميل على القائد — M · تم النقل، قواعد مطابقة الاستجابات
• تشكيلات نشر فعلية (Docker وKubernetes وغيرها) — نشر خادم Ticketing