التوثيق

الانتعاش وإعادة التشغيل

تصف “Freshness” مدى حداثة توقعات عملية القراءة بالنسبة لسجل الالتزام. “Replay” هو الآلية التي تحافظ على تزامن التوقعات.

المشكلة التي يحلها هذا المفهوم

في أنظمة المصدر الحدثي، يتم فصل الكتابات والقراءات:

  • يقوم برنامج الكتابة بتسجيل الأحداث على الفور
  • يجب على الـ daemon قراءة تلك الأحداث لمعالجة تحديث رؤيته

هذا يخلق فجوة الانتعاش: الوقت بين الاعتراف بالتزام ما وظهوره في استعلامات القراءة. فهم هذه الفجوة أمر أساسي لـ:

  • بناء تطبيقات تحتاج إلى قراءات متسقة
  • تشخيص “قدم” البيانات الظاهرة
  • ضبط أداء النظام

الأفكار الأساسية

سجل الالتزام

سجل الالتزام هو التسلسل الدائم لمجموعات الأحداث:

  • إضافة فقط: يتم إضافة دفعات جديدة في النهاية
  • غير قابل للتغيير: بمجرد الكتابة، لا تتغير الدفعات
  • متسلسل: كل دفعة تحتوي على رقم تسلسل أحادي الاتجاه

تقوم عملية الكتابة بإضافة إلى السجل؛ بينما تقوم عملية القراءة بمتابعته.

التوقعات

تعتبر التوقعات وجهات نظر في الذاكرة عن الحالة:

  • تم بناؤه من خلال تطبيق الأحداث من سجل الالتزام
  • مُحسَّن لأداء الاستعلام
  • تم النشر بشكل ذري عبر تبديل اللقطة

التحليلات هي بيانات مشتقة. إذا فقدت، يمكن إعادة بنائها من سجل الالتزام.

نقاط التفتيش

تسجل نقاط التفتيش التقدم من خلال سجل الالتزام:

إرشادات إضافية:

  • كتابة daemon: تتبع آخر تسلسل تم الالتزام به
  • خدمة القراءة: تتبع آخر تسلسل تم تطبيقه

نقاط التفتيش تمكّن:

  • بدء سريع (استئناف من نقطة التحقق، وليس من البداية)
  • استرداد من الأعطال (إعادة التشغيل من نقطة التحقق)
  • حساب النضارة (مقارنة نقاط التفتيش)

بيانات تحديث النضارة

تتضمن ردود القراءة معلومات عن النضارة:

{
  "freshness": {
    "checkpoint_seq": 42,
    "commit_log_seq": 45
  }
}
  • checkpoint_seq: تسلسل المعالجة الذي قام به خادم القراءة
  • commit_log_seq: أحدث تسلسل في سجل الالتزام

الفرق هو التأخير: عدد الالتزامات التي لم يتم تطبيقها بعد.

عملية إعادة التشغيل

عندما يتتبع خادم القراءة سجل الالتزام:

  1. استرجاع الدفعة التالية بعد نقطة التحقق
  2. تطبيق كل حدث عبر إعدادات L1
  3. تحديث نقطة التحقق
  4. نشر لقطة جديدة

الأحداث هي idempotent: تطبيق نفس الحدث مرتين ينتج نفس الحالة. هذا يجعل إعادة التشغيل آمنة لإعادة المحاولة.

تدفق الاسترداد

بعد حدوث عطل:

  1. تحميل نقطة التحقق من القرص
  2. استرجاع الأحداث من موضع نقطة التحقق
  3. إعادة تشغيل الأحداث لإعادة بناء الحالة
  4. استئناف حلقة الذيل العادية

لأن الأحداث تحمل حالة ما بعد التنفيذ، فإن إعادة التشغيل لا تحتاج إلى إعادة تنفيذ منطق الأعمال. إنها ببساطة تعين القيم النهائية.

كيف يتناسب مع النظام

كتابة المسار

Client → Write Daemon → Commit Log
                         ↓
              [checkpoint updated]

تقوم عملية الكتابة بتحديث نقطة التحقق الخاصة بها بعد نجاح عملية الحفظ.

مسار القراءة

Commit Log → Read Daemon → Projections → Client
    ↓
[checkpoint updated after apply]

ينشر برنامج التشغيل (daemon) لقطات (snapshots) قبل تحديث نقطة التحقق (checkpoint) الخاصة به. هذا يضمن:

  • الاستعلامات دائمًا ترى حالة متسقة
  • لا تفقد الأعطال العمل المطبق ولكن غير المحجوز

تقارير النضارة

تقرير تأخر نقطة النهاية الصحية:

{
  "commit_log": {
    "end_seq": 100,
    "checkpoint_seq": 98,
    "lag": 2
  }
}

راقب هذا لاكتشاف:

  • التشغيل العادي (التأخير قريب من 0)
  • انفجار مؤقت (ارتفاعات تأخير ثم استعادة)
  • القضايا النظامية (التأخير ينمو باستمرار)

الثوابت الرئيسية والضمانات

الاتساق النهائي

ستعكس التوقعات في النهاية جميع الأحداث الملتزمة:

  • يقوم الـ daemon بمتابعة السجل بشكل مستمر
  • قد يرتفع التأخير خلال الفترات القصيرة ولكنه يتعافى
  • لا يوجد حدث ملتزم غير مرئي بشكل دائم

نشر-قبل-نقطة-التفتيش

تُنشَر اللقطات قبل تحديث نقاط التحقق:

إرشادات إضافية:

  • الاستعلامات ترى البيانات التي يتم ضمان تطبيقها
  • لا تتسبب الأعطال في “اختفاء” البيانات
  • استعادة إعادة التشغيل من آخر نقطة آمنة

إعادة التشغيل الحتمية

إعادة التشغيل تنتج حالة متطابقة:

إرشادات إضافية:

  • الأحداث تحمل قيم ما بعد الحالة
  • لا توجد منطق أعمال أثناء إعادة التشغيل
  • نفس الأحداث → نفس الحالة

سلامة نقاط التفتيش

تُحفظ نقاط التفتيش بشكل ذري:

إرشادات إضافية:

  • لا توجد كتابات جزئية لنقاط التفتيش
  • الاسترداد دائمًا يجد نقطة تفتيش صالحة
  • التقدم لا يُفقد أبداً عبر إعادة التشغيل

انظر أيضًا