قد تحفظ خدمة طلبًا في قاعدة البيانات ثم تفشل في إرسال حدث «تم إنشاء الطلب» إلى نظام آخر. وقد يحدث العكس إذا أرسلت الحدث أولًا ثم فشلت المعاملة. يساعد نمط Transactional Outbox على ربط حفظ البيانات وتسجيل نية الإرسال في معاملة واحدة، ثم نقل الحدث لاحقًا بطريقة قابلة للاستئناف.
احفظ البيانات والحدث داخل المعاملة نفسها
عند إنشاء الطلب، اكتب سجل الطلب وسجل outbox الذي يصف الحدث داخل معاملة قاعدة بيانات واحدة. إذا فشلت المعاملة لا يظهر أي منهما، وإذا نجحت يبقى الحدث محفوظًا حتى لو تعطلت عملية النشر. لا ترسل رسالة الشبكة الخارجية أثناء معاملة طويلة إذا كان ذلك يزيد احتجاز الأقفال ويجعل الفشل صعب التنبؤ.
افصل عامل الإرسال عن منطق الطلب
يقرأ عامل مستقل سجلات outbox غير المنشورة، ثم يرسلها إلى الوسيط أو المستهلك ويحدث حالتها. يمكن استخدام الاستطلاع أو آلية التقاط تغييرات قاعدة البيانات بحسب البنية. ضع حدودًا لحجم الدفعات وعدد المحاولات، ولا تجعل حدثًا معطوبًا يوقف إرسال جميع الأحداث التالية إلى الأبد.
توقع التكرار رغم نجاح النمط
قد يصل الحدث إلى الوسيط ثم يتعطل العامل قبل تسجيل نجاح الإرسال، فيعيد المحاولة لاحقًا. لذلك لا يضمن Outbox تسليمًا مرة واحدة بالضبط. امنح كل حدث معرفًا ثابتًا واجعل المستهلك يمنع تكرار الأثر أو يعالج التكرار بأمان. اختبر هذه الحالة تحديدًا بدل الاعتماد على نجاح المسار العادي.
راقب التأخر وتراكم السجلات
سجّل عمر أقدم حدث غير منشور، وعدد المحاولات الفاشلة، ومعدل الإرسال، وحجم الجدول. ضع سياسة تنظيف للسجلات المؤكدة دون حذف ما يحتاجه التحقيق أو إعادة التشغيل. إذا ارتفع عمر الحدث، فقد يكون النظام الأساسي يعمل بينما تتأخر الفواتير أو الإشعارات؛ وهذا عطل وظيفي يجب رصده.
مثال عملية شراء
ينشئ العميل طلبًا وتُحفظ حالته مع حدث order.created داخل المعاملة نفسها. إذا تعطل وسيط الرسائل، يظل الطلب محفوظًا ويبقى الحدث في outbox حتى عودة الاتصال. وعند إعادة الإرسال يتحقق نظام الفواتير من معرف الحدث قبل إنشاء فاتورة، فلا تتحول إعادة المحاولة إلى عملية مكررة.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…