menuTicketing

نشر خادم Ticketing

بيئة التشغيل
الوضع
bash
مثال اتصال العميل
rust
اختبار سريع nc
bash

متغيرات البيئة

يمكن ضبط كل عنصر في ticketing.toml (اختياري) أيضًا عبر متغير بيئة. الأولوية هي متغير البيئة > ticketing.toml > القيمة الافتراضية، ولا تُفرَّق المفاتيح والقيم المنطقية (boolean) بين حروف كبيرة وصغيرة. صورة Docker مبنية على scratch لذا حقن الإعدادات عبر متغيرات البيئة هو الأسلوب الافتراضي (لاستخدام ملف إعدادات بدلًا من ذلك، اربطه (mount) وحدّد مساره عبر CONFIG).

متغير البيئةالقيمة الافتراضيةالوصف
PORT (SERVER_PORT)5225منفذ الاستماع عبر TCP. يُتجاهل في وضع العنقود، حيث يُستخدم بدلًا منه المنفذ الوارد في CLUSTER_SELF
DEBUG (SERVER_DEBUG)يعتمد على البناء (build)تفعّل القيمة 1/true سجلّات debug
SOCKET_BIND0.0.0.0عنوان الاستماع
SOCKET_NODELAYtrueTCP_NODELAY
SOCKET_READ_BUF_LEN4096حجم مخزن القراءة لكل اتصال (بايت)
SOCKET_REPLY_QUEUE1024طول قائمة انتظار الاستجابات لكل اتصال
SOCKET_REPLY_BATCH64أقصى عدد استجابات تُجمَّع في عملية كتابة واحدة
SWEEP_INTERVAL_SECS5فترة تنظيف المفاتيح المنتهية الصلاحية (بالثواني)
CLUSTER_SELF(لا شيء)العنوان المُعلَن لهذه العقدة، بصيغة host:port. وجوده يفعّل وضع العنقود
CLUSTER_PEERS(لا شيء)قائمة عناوين العقد مفصولة بفواصل. الترتيب = أولوية الترقية، ويجب أن تتضمن self، بحدّ أدنى عنصرين
CONFIG./conf/ticketing.tomlمسار ملف الإعدادات

فردي مقابل عنقودي

  • فردي (خادم واحد): بدون [cluster] (أو CLUSTER_*)، تعمل العقدة بشكل مستقل. الأسرع، لكن يحدث انقطاع قصير عند إعادة التشغيل، وتُفقَد الحالة المخزّنة في الذاكرة عند إعادة التشغيل (lease هي شبكة الأمان).
  • عنقودي (بلا توقف خدمة): بحدّ أدنى خادمان. تمتلك كل عقدة نفس CLUSTER_PEERS (بترتيب الأولوية) و**CLUSTER_SELF** الخاص بها الذي يشير إلى نفسها. من بين العقد الحية، تصبح العقدة ذات الأعلى أولوية نشطة، وتصبح البقية عقدًا احتياطية تتلقى نسخًا مطابقة في الوقت الفعلي. للتفاصيل، راجع آلية العمل والبروتوكول — خادم ↔ خادم.

يستخدم نشر العنقود على Kubernetes StatefulSet + خدمة بلا رأس (headless Service). امنح كل pod اسم DNS ثابتًا (ticketing-0.ticketing…، ticketing-1.ticketing…)، وأدرج هذه الأسماء في CLUSTER_PEERS بترتيب الأولوية، واحقن CLUSTER_SELF الخاص بكل pod تلقائيًا عبر downward API (metadata.name).

إعادة تشغيل بلا توقف خدمة (متدرّجة/rolling)

  1. أعد تشغيل العقد الاحتياطية أولًا، واحدة تلو الأخرى (تستمر العقدة النشطة في تقديم الخدمة طوال ذلك).
  2. أخيرًا، أوقف العقدة النشطة (Ctrl+C) — يؤدي التسليم (handoff) إلى ترقية عقدة احتياطية وانتقال العملاء إليها.
  3. عند إعادة تشغيل العقدة النشطة القديمة التي أُوقفت، تنضم كعقدة احتياطية للعقدة النشطة الحالية (لا توجد عودة تلقائية/failback).

مرجع

  • الصورة: sarolab/ticketing · Github: saro-lab/ticketing
  • سجّل جميع عناوين العقد في العميل (الوسيط/broker) ليتم التبديل تلقائيًا عند حدوث عطل. للاطلاع على الاستخدام الخاص بكل لغة، راجع المكتبات.