آلية العمل ​

تتتبع هذه الصفحة تدفق الرسائل الفعلي بين العميل والخادم (العنقود) لشرح آلية عمل Ticketing. المواصفات الدقيقة على مستوى البايت لما يعبر السلك موجودة في البروتوكول (API) والبروتوكول (العنقود).

البنية العامة ​

الخدمات التي تستقبل طلبات المستخدمين (مثل خوادم الأحداث التي تعالج فتح بيع التذاكر) تصطف بنفس المفتاح أمام عنقود Ticketing، والخادم الذي يحين دوره فقط هو من يواصل العمل مثل خصم المخزون أو تخصيص مقعد.

الحصول على القفل وتحريره ​

هذا هو التدفق الأساسي. المفتاح غير المحجوز يُمنح فورًا؛ والمفتاح المحجوز ينتظر دوره في طابور FIFO. عندما يحرر الحائز القفل، يُسلَّم مباشرة إلى مقدمة الطابور دون إعادة تنافس — ينتقل المنتظر التالي فورًا برمز جديد، فلا توجد لحظة يكون فيها القفل فارغًا، ولا يمكن لأحد التسلل.

• lease شبكة أمان. إذا مات العميل أو نسي التحرير، يستعيد الخادم المفتاح بعد انقضاء مدة lease ويسلّمه للمنتظر التالي. اضبطها بسخاء — أطول من أسوأ زمن قد تستغرقه منطقتك الحرجة. يقبل v1 مدة من 1 إلى 250 ثانية فقط؛ والعمل الأطول غير مدعوم صراحةً ويُرفض.
• wait هو الحد الأقصى لانتظار العميل. إذا لم يحن دوره خلال تلك المدة، يستجيب الخادم بـ T (انتهاء المهلة) بدلًا من منح القفل، فلا يتسرب أي قفل. 0 تعني محاولة فورية واحدة دون دخول الطابور. لا يوجد انتظار غير محدود.
• إذا حاول العميل نفسه إعادة الحصول على مفتاح يحوزه بالفعل، فإنه يصطف مثل أي منتظر آخر — هذا ليس قفلًا قابلًا لإعادة الدخول (reentrant).

راجع مصفوفة الطلب × حالة المفتاح للقواعد الكاملة لسلوك الخادم حسب حالة المفتاح، وقيود الحقول لنطاقات قيم الحقول.

رموز Fencing ​

حتى خادم قفل مثالي لا يستطيع التحكم بساعة العميل. Ticketing وحده لا يستطيع منع حالة الحائز المتقادم: عميل توقف لفترة بسبب توقفات GC أو حمل زائد وهو حائز للقفل، ثم استيقظ — دون علم بانتهاء lease الخاص به — وواصل عمله. لهذا فإن token في كل استجابة حصول هو عدد صحيح u64 مضمون التزايد مع كل منح. في قواعد البيانات المالية أو الدائمة، يجب أن تكون مقارنة high-water لـfencing لكل مفتاح وتحديثه ذرّية مع business write الفعلية في DB transaction نفسها أو conditional write واحدة. تحديث fencing row وحده أولًا ثم تنفيذ الكتابة الفعلية لاحقًا غير آمن.

يستمر التزايد الأحادي عبر العنقود أيضًا — فرقم إصدار الرمز نفسه يُكرَّر عبر الإجماع، لذا حتى بعد تغيير القائد، يواصل القائد الجديد دائمًا من رقم أكبر من السابق. راجع رمز Fencing (المواصفات) للصيغة الدقيقة للحقل.

العنقود — انعدام التوقف عبر إجماع Raft ​

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

• إذا مات القائد، تنتخب الإعدادات الحالية قائدًا جديدًا خلال 2.3 إلى 2.5 ثانية تقريبًا. لا يجوز متابعة acquire المنطقي نفسه ضمن ميزانية wait المتبقية إلا إذا لم يُرسل أي byte من الطلب. acquire المُرسل دون استجابة مؤكدة هو Indeterminate ولا يُعاد إرساله تلقائيًا أبدًا.
• حتى انتهاء lease يمر عبر الإجماع. لا يختفي القفل إلا بعد أن يثبّت القائد أمر الانتهاء، فاختلاف الساعات الطفيف بين العُقد لا يتسبب أبدًا في تباين حالة القفل.
• إذا فقد العنقود أغلبيته (مثل تعطل 2 من 3 عُقد)، يتوقف عن قبول الكتابة بدلًا من المخاطرة بإصدار قفل خاطئ (الأمان أولًا). إذا فُقدت volatile process state في عقدتين من 3 (أو 3 من 5)، فلا يجوز استرداد cluster/fencing domain ذاك أو bootstrap تلقائيًا بالهوية نفسها.

بما أن الأغلبية هي الأساس، لا يُسمح إلا بـ 3 أو 5 عُقد. عدد العُقد الزوجي يزيد التكلفة فقط دون تحسين تحمّل الأعطال، لذا يرفض الخادم البدء بعدد زوجي.

راجع البروتوكول (العنقود) لقواعد إطارات ومنافذ RPC بين الأقران، واستبدال learner بـNodeId جديد دون توقف لاستبدال العُقد واحدة تلو الأخرى.

سلوك العميل ​

تشترك العملاء الرسميون في السلوك التالي (راجع المكتبات للواجهات البرمجية الخاصة بكل لغة).

• يحافظ على اتصال دائم واحد لكل عنوان في الخلفية. عند إعطاء عنوان واحد فقط، يحافظ على اتصالين بنفس العقدة، فانقطاع مقبس واحد لحظيًا لا يوقف الخدمة.
• يختار اتصالًا بالقائد أولًا، ثم بالتناوب (round-robin). يتذكر القائد الذي وُجِّه إليه آخر مرة عبر M ويرسل الطلبات التالية إليه مباشرة.
• الطلبات تمر بالأنبوب (pipelining). يمكن إرسال الطلب التالي دون انتظار الاستجابة — راجع قواعد مطابقة الاستجابات لكيفية إقران الاستجابات بالطلبات.
• الاتصال المنقطع يواصل إعادة المحاولة بتراجع أسّي (من 0.1 ثانية حتى سقف 3.2 ثانية). الاتصال الميت لا يُفسد كائن الوسيط (broker) — يتعافى من تلقاء نفسه.
• لا يُعاد acquire المنطقي نفسه داخليًا إلا إذا لم يُرسل أي byte من الطلب. B المرتبط نتيجة Busy/عدم حصول مؤكدة ويُعاد فورًا إلى caller بلا retry داخلي. M مجرد leader hint للاتصال التالي؛ ولأنه بلا owner/key فليس دليلًا لإعادة طلب pending سبق إرساله. acquire المُرسل دون استجابة مؤكدة يُبلَّغ Indeterminate، ولا يجوز للعميل دخول critical section.
• يستخدم explicit release وتعويض known-token تطابق owner/token/key الدقيق وطابورًا مخصصًا bounded. ينتهي retry عند deadline مطلق قدره 5 ثوانٍ من request/enqueue، لا عند lease المتبقي. دون استجابة نجاح، لا يُبلَّغ explicit release ناجحًا ولا يُفترض كذلك؛ server-side lease هو شبكة الأمان الأخيرة.

الاتصال والأمان ​

يُنشأ كل اتصال (عميل أو نظير) بالترتيب TCP ← (TLS) ← مصادقة challenge-response. يُجزّئ العميل الرقم العشوائي (nonce) المرسل من الخادم مع رمزه للاستجابة، فلا يُرسَل الرمز عبر السلك كنص صريح أبدًا، ورقم عشوائي جديد في كل اتصال يمنع إعادة الاستخدام (replay). راجع مصافحة المصادقة للمواصفات الدقيقة.

ملاحظة حول الاتساق ​

• الاستبعاد المتبادل مضمون بالإجماع. بما أن كل منح يمر عبر تثبيت الأغلبية، لا يُصدَر نفس المفتاح لحائزين في آن واحد، حتى أثناء انقسام الشبكة أو تغيير القائد.
• يجب فرض fencing في قواعد البيانات الدائمة. لا يوقف عميلًا يستيقظ بعد انتهاء lease إلا شرط high-water لكل مفتاح، منفذًا ذريًا مع protected write في transaction/conditional write نفسها. القفل يرتب العمل؛ وDB fencing يمنع آخر stale write.