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

تصف النضارة مدى حداثة توقعات عملية القراءة بالنسبة لسجل الالتزام. إعادة التشغيل هي الآلية التي تحافظ على تزامن التوقعات. فهم كلاهما ضروري لتشغيل Asset Core على نطاق واسع دون مفاجآت من الركود.

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

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

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

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

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

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

سجل الالتزام

سجل الالتزام هو تسلسل دفعات الأحداث القابل للإضافة فقط. إنه المصدر الوحيد المستخدم لإعادة بناء التوقعات، لذا فإنه يحدد الجدول الزمني المعتمد. تعتمد المتانة على الخلفية: سجلات الذاكرة السريعة والقابلة للتخلص، بينما تستمر سجلات الملفات/المجزأة عبر إعادة التشغيل. هذا التصميم (المغطى في نموذج التشغيل) هو ما يجعل ضمانات AssetCore ممكنة.

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

تقوم عملية الكتابة بإضافة البيانات إلى السجل؛ بينما تقوم عملية القراءة بمتابعتها. هذه الفجوة حاسمة: عملية الكتابة لا تعيق أداء القراءة، ويمكن لعملية القراءة أن تتأخر دون التأثير على معدل الكتابة. ما تكسبه: توسيع الكتابة والقراءة بشكل مستقل، واستعادة البيانات بعد الانهيار عند استخدام واجهة سجل دائمة، وتصحيح الأخطاء الجنائية من خلال إعادة التشغيل إلى أي نقطة. ما تتخلى عنه: القراءات متسقة في النهاية، وليست متسقة على الفور - هناك دائمًا بعض التأخير.

توقعات

التمثيلات هي وجهات نظر في الذاكرة للحالة. تم تحسينها للاستعلامات ويمكن دائمًا إعادة بنائها من السجل، وهذا هو السبب في أن إعادة التشغيل هي ثبات أساسي. هذا الفصل بين “مصدر الحقيقة” (سجل الالتزام) و”واجهة الاستعلام” (التمثيلات) هو أساس بنية AssetCore.

• تم بناؤه من خلال تطبيق الأحداث من سجل الالتزام (عملية إعادة التشغيل، انظر أدناه)
• تم تحسينه لأداء الاستعلامات (مؤشر، غير مُعَدل لعمليات البحث السريعة)
• تم نشره بشكل ذري عبر تبديل اللقطة (لا توجد تحديثات جزئية مرئية للاستعلامات)

التحليلات هي بيانات مشتقة. إذا فقدت، يمكن إعادة بنائها من سجل الالتزام. هذه الخاصية هي ما يجعل AssetCore بسيطًا من الناحية التشغيلية: يمكنك دائمًا إعادة بناء حالة الاستعلام من السجل، والدوام هو خيار نشر. بدون ذلك، فإن فقدان خادم القراءة يعني فقدان البيانات أو بروتوكولات تكرار معقدة. مع ذلك، فإن فقدان خادم القراءة هو أمر غير مريح (وقت إعادة البناء) ولكنه ليس كارثيًا.

ما تكسبه: حالة استعلام قابلة للتخلص (إعادة بناء عند الحاجة)، حرية تغيير هيكل العرض (إعادة تشغيل بمنطق جديد)، الثقة بأن التحليلات/الإشعارات لا تنحرف أبداً عن الحالة التشغيلية (الجميع يستهلك نفس السجل). ما تتخلى عنه: وقت إعادة البناء بعد الأعطال يتناسب مع حجم السجل، على الرغم من أن نقاط التحقق تجعل هذا قابلاً للإدارة.

نقاط التفتيش

تسجل نقاط التفتيش التقدم من خلال سجل الالتزام. تجعل عملية الاسترداد سريعة وتسمح لك بالتفكير بدقة في مقدار الحالة التي تم تطبيقها. بدون نقاط التفتيش، سيتطلب كل إعادة تشغيل إعادة تشغيل السجل بالكامل من البداية - وهو أمر ممكن للأنظمة الصغيرة، ولكنه كارثي لأحمال العمل الإنتاجية التي تحتوي على ملايين الأحداث.

• خدمة الكتابة: تتعقب آخر تسلسل تم الالتزام به (حتى تعرف أين تستأنف بعد حدوث عطل)
• خدمة القراءة: تتعقب آخر تسلسل تم تطبيقه (حتى تتمكن من استئناف التشغيل دون إعادة تطبيق الأحداث)

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

• بدء سريع: استئناف من نقطة التحقق، وليس من البداية (إعادة تشغيل 1,000 حدث بدلاً من 1,000,000)
• استرداد من الأعطال: إعادة التشغيل من موقع نقطة التحقق للأمام (انظر نموذج التشغيل)
• حساب النضارة: قارن علامات تسلسل المياه العالمية (التأخير = commit_log_seq - projection_seq)

ما تكسبه: وقت بدء التشغيل يقاس بالثواني وليس بالساعات، نوافذ استرداد قابلة للتنبؤ، مراقبة انتعاش في الوقت الحقيقي. ما تتخلى عنه: عبء نقاط التحقق (كتابات لقطة دورية)، على الرغم من أنها خفيفة الوزن وقابلة للتكوين.

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

تتضمن استجابات القراءة معلومات عن النضارة؛ يمكن للعملاء تمرير x-assetcore-min-world-seq للحظر حتى تسلسل أدنى. هذه هي الطريقة التي تفرض بها قراءة كتاباتك والتناسق الصارم عند حدود العميل. بدون تتبع نضارة صريح، لن يكون لديك أي فكرة عما إذا كانت الاستعلامات قد أعادت بيانات قديمة أو بيانات جديدة - يصبح تصحيح الأخطاء تخمينًا.

{
  "freshness": {
    "namespace": 1,
    "world_seq": 42,
    "commit_log_world_seq": 45,
    "lag": 3,
    "lag_ms": 125
  }
}

• world_seq: أحدث تسلسل تم تطبيقه على عرض القراءة (ما تراه الاستعلامات)
• commit_log_world_seq: أحدث تسلسل سجل الالتزام الملاحظ (ما تم الالتزام به)
• lag: الفرق في الالتزامات (عدد الدفعات المتأخرة)
• lag_ms: فرق الوقت بالميلي ثانية (مدى قدم البيانات)

الفرق هو التأخير: عدد الالتزامات التي لم يتم تطبيقها بعد (وكم هو طول هذه الفجوة بالميلي ثانية). هذا التأخير هو أمر طبيعي ومتوقع في الأنظمة المعتمدة على الأحداث - إنه تكلفة فصل الكتابة/القراءة. الجزء الحاسم هو أنه مقاس ومكشوف، وليس مخفيًا.

ما تكسبه: رؤية في قدم البيانات (معرفة متى تكون البيانات جديدة)، القدرة على فرض الاتساق (حظر القراءة حتى تكون جديدة بما يكفي)، رؤى تصحيح الأخطاء (ربط مشاكل الاستعلام مع ارتفاعات التأخير). ما تتخلى عنه: أحجام استجابة أكبر قليلاً (بيانات تعريف الحداثة في كل قراءة)، لكن القيمة التشغيلية تستحق ذلك.

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

إعادة التشغيل هي الآلية التي تحافظ على تزامن التوقعات مع سجل الالتزام. إنها ليست مجرد ميزة استرداد—إنها الحلقة التشغيلية الأساسية لخادم القراءة. فهم إعادة التشغيل يعني فهم كيفية عمل AssetCore.

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

1. استرجاع الدفعة التالية بعد نقطة التحقق (من تخزين سجل الالتزام)
2. تطبيق كل حدث عبر إعدادات L1 (انظر نموذج التشغيل للحصول على تفاصيل الطبقات)
3. تحديث نقطة التحقق (تسجيل التقدم)
4. نشر لقطة جديدة (تبادل ذري، لا تحديثات جزئية مرئية)

الأحداث هي متماثلة: تطبيق نفس الحدث مرتين ينتج نفس الحالة. هذا يجعل إعادة التشغيل آمنة لإعادة المحاولة وهو ما يمكّن من الاسترداد الحتمي بعد الفشل الجزئي. والأهم من ذلك، يعني أن إعادة التشغيل ليست هشة—إذا كنت غير متأكد مما إذا كان قد تم تطبيق حدث، فقط قم بتطبيقه مرة أخرى.

لماذا تعتبر إعادة التشغيل ميزة قاتلة: ليست مجرد استعادة من الأعطال. إنها تصحيح الأخطاء عبر الزمن (إعادة التشغيل إلى الساعة 3:47 مساءً يوم الثلاثاء وفحص الحالة الدقيقة)، المحاكاة (إعادة تشغيل أحداث الإنتاج ضد المنطق التجريبي)، التحليلات (إعادة تشغيل السجل إلى هيكل عرض مختلف)، والاختبار (التحقق من السلوك مقابل تدفقات الأحداث الحقيقية). الأنظمة التي لا تحتوي على إعادة تشغيل حتمية لا يمكنها القيام بأي من هذا بشكل موثوق.

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

بعد حدوث عطل، يستعيد AssetCore النظام تلقائيًا دون تدخل يدوي. هذه واحدة من أكثر الخصائص قيمة من الناحية التشغيلية في البنية المعمارية—لا حاجة لاستعادة الحالة يدويًا في الساعة الثالثة صباحًا.

بعد حدوث عطل:

1. تحميل نقطة التحقق من القرص (آخر لقطة حالة معروفة جيدة)
2. جلب الأحداث من موضع نقطة التحقق (فقط الأحداث التي لم يتم تطبيقها بعد)
3. إعادة تشغيل الأحداث لإعادة بناء الحالة (عبر L1 setters، سريع وحتمي)
4. استئناف حلقة الذيل العادية (العودة إلى حالة التشغيل الثابتة)

لأن الأحداث تحمل حالة ما بعد (انظر نموذج التشغيل)، فإن إعادة التشغيل لا تحتاج إلى إعادة تنفيذ منطق الأعمال. إنها ببساطة تضبط القيم النهائية، مما يقضي على عدم الحتمية أثناء الاسترداد. هذا ما يجعل الاسترداد سريعًا (بدون عبء تحقق) وموثوقًا (بدون إمكانية الانحراف).

ما تكسبه: استرداد تلقائي (بدون خطوات يدوية)، وقت استرداد متوقع (يتناسب مع الأحداث منذ نقطة التحقق)، ثقة بأن الحالة المستردة مطابقة بالبايت للحالة قبل التعطل. ما تتخلى عنه: الاسترداد ليس فوريًا - يستغرق وقتًا يتناسب مع فترة نقطة التحقق، لكن هذا عادة ما يكون ثوانٍ وليس دقائق.

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

اكتب المسار

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

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

مسار القراءة

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

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

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

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

نقطة نهاية قراءة الصحة تبلغ عن التأخير في مساحة الاسم:

{
  "status": "ready",
  "freshness": {
    "namespace": 1,
    "world_seq": 98,
    "commit_log_world_seq": 100,
    "lag": 2,
    "lag_ms": 250
  }
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

انظر أيضًا

• نموذج التشغيل - كيف يتناسب إعادة التشغيل مع البنية المعمارية
• الصحة والمقاييس - مراقبة الانتعاش
• HTTP API - الحداثة في استجابات واجهة برمجة التطبيقات