نموذج وقت التشغيل
نموذج التشغيل يحدد كيفية معالجة Asset Core لتغييرات الحالة وتقديم الاستفسارات مع ضمانات حتمية وقابلة للتدقيق.
المشكلة التي يحلها هذا المفهوم
تواجه الأنظمة الموزعة توتراً أساسياً بين التناسق، والتوافر، وتحمل التقسيم. غالباً ما تضحي الأساليب التقليدية بأحد هذه العناصر لتحقيق الآخرين، مما يؤدي إلى:
- حالات السباق عندما يقوم كتاب متعددون بتحديث نفس الحالة
- التحديثات المفقودة عندما تتداخل التغييرات المتزامنة مع بعضها البعض
- سلوك غير حتمي يجعل عملية تصحيح الأخطاء والتدقيق صعبة
- بروتوكولات التوافق المكلفة التي تضيف تأخيرًا وتعقيدًا
تحل Asset Core هذه المشكلات من خلال اعتماد بنية كاتب واحد مع مصدر الأحداث، مما يتيح تداول قابلية الكتابة الأفقية مقابل الحتمية المطلقة والبساطة.
الأفكار الأساسية
عالم الكتابة الفردية
لكل عالم كاتب واحد فقط. هذا يلغي:
- عبء التنسيق بين الكتاب
- حالات السباق على تغييرات الحالة
- الحاجة إلى الأقفال الموزعة أو التوافق
يعمل برنامج الكتابة على تسلسل جميع الالتزامات من خلال خط أنابيب واحد. بينما يحد هذا من معدل الكتابة إلى ما يمكن أن تتعامل معه عقدة واحدة، فإنه يضمن أن كل التزام يرى عرضًا متسقًا للعالم.
سجل الالتزام كمصدر للحقائق
تُسجل جميع تغييرات الحالة كأحداث في سجل التزام يُضاف إليه فقط:
- يتم تجميع الأحداث في دفعات قبل الإقرار
- يتم الاحتفاظ بالدفعات بشكل دائم قبل أن تتلقى العملاء استجابات النجاح
- السجل هو السجل المعتمد لكل ما حدث
هذا التصميم يمكّن من إعادة التشغيل الحتمية: عند إعطاء نفس تسلسل الأحداث، سيقوم أي قارئ بإعادة بناء نفس الحالة.
التوقعات
تُعتبر التوقعات وجهات نظر مُحسّنة للقراءة عن الحالة المستمدة من سجل الالتزام:
- يقوم الـ daemon بمتابعة سجل الالتزام للدفعات الجديدة
- يتم تطبيق الأحداث عبر إعادة التشغيل لتحديث الحالة في الذاكرة
- يتم نشر اللقطات بشكل ذري لخدمة الاستعلام
التوقعات تتوافق في النهاية مع سجل الالتزام. الفجوة بين الأحداث الملتزمة والتوقعات المنشورة هي فجوة الحداثة.
بنية ثلاثية الطبقات
يفصل وقت التشغيل الاهتمامات عبر ثلاث طبقات:
| الطبقة | المسؤولية | السلوك |
|---|---|---|
| L1 (التخزين) | تغييرات البيانات الخام | لا تحقق، لا أحداث |
| L2 (العمليات) | المنطق التجاري | يتحقق من الشروط المسبقة، يصدر أحداث |
| L3 (المعاملات) | التنسيق | يسجل التراجع، يتعامل مع إعادة التشغيل |
هذا الفصل يضمن أن:
- عمليات التخزين سريعة وقابلة للتنبؤ
- يتم تطبيق قواعد العمل بشكل متسق
- يمكن التراجع عن المعاملات بشكل ذري
كيف يتناسب مع النظام
نموذج التشغيل يشكل كل جانب من جوانب Asset Core:
مسار الكتابة:
- العميل يرسل طلب الالتزام
- يقوم الـ daemon بالتحقق من صحة وتنفيذ العمليات (L2/L3)
- يتم ختم الأحداث والحفاظ عليها في سجل الالتزام
- يتلقى العميل النجاح مع رقم التسلسل
مسار القراءة:
- قراءة سجل التزام ذيول الخدمة
- يتم إعادة تشغيل الأحداث عبر L1 setters (idempotent)
- يتم نشر التوقعات عبر التبادل الذري
- الاستعلامات المقروءة من العرض الحالي
الاسترداد:
- تحميل نقطة التحقق (آخر حالة معروفة جيدة)
- إعادة تشغيل الأحداث من موقع نقطة التحقق
- استئناف التشغيل العادي
الثوابت الرئيسية والضمانات
الحتمية
نظرًا لتسلسل الأحداث نفسه، فإن إعادة التشغيل تنتج حالة متطابقة. يتطلب هذا:
- العمليات تصدر حالة ما بعد في الأحداث (ليس دلتا)
- إعادة التشغيل تستخدم L1 setters (لا حسابات، لا تحقق)
- لا توجد تبعيات خارجية أثناء إعادة التشغيل
الاستقرارية
تطبيق نفس الحدث مرتين ليس له تأثير إضافي:
إرشادات إضافية:
- الأحداث تحمل الحالة النهائية للتعيين
- إعادة التشغيل ببساطة تكتب فوق تلك الحالة
- آمن لإعادة المحاولة بعد الفشل
الذرية
تنجح جميع العمليات في الالتزام أو تفشل معًا:
- تسجل L3 خطوات التراجع أثناء التنفيذ
- تؤدي الأخطاء إلى تراجع جميع التغييرات
- لا توجد التزامات جزئية مرئية
سلامة التصادم
يستعيد النظام بشكل صحيح من الأعطال:
- سجل الالتزام يبقى بعد إعادة التشغيل
- تسجل نقاط التفتيش التقدم
- يعيد التشغيل إعادة بناء أي حالة مفقودة
انظر أيضًا
- الانتعاش وإعادة التشغيل - مدى “انتعاش” البيانات المقروءة
- المعاملات والعمليات - الوحدة الذرية للتغيير
- كتابة بنية المسار - الغوص العميق في خط الأنابيب