تحديث التطبيقات باستخدام Laravel: الطوابير وعدم التكرار (Idempotency) والترحيل الآمن

اختر نطاقًا صغيرًا بما يكفي للتحقّق منه

يمكن للترحيل التدريجي أن يقلّص نطاق كل إصدار، لكنه ليس خاليًا من المخاطر. ابدأ بمسار عمل محدود تُعرف مدخلاته ومخرجاته والمسؤولون عنه جيدًا. ارسم خريطة لنموذج البيانات القديم والآثار الجانبية الخارجية واعتماديات التقارير قبل تحويل أي حركة مرور.

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

اجعل عمليات الكتابة الحرجة ضمن معاملة

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

يمكن لقفل Redis أن ينسّق العمل، لكن انتهاء مدة الحجز أو تعطّل العملية أو مفتاح بنطاق خاطئ قد يسمح بتداخل التنفيذ. فهو لا يغني عن قيود قاعدة البيانات. وثّق أي نظام مسؤول عن كل ثابت، واختبره بطلبات متزامنة.

لا ترسل المهمة إلا بعد اعتماد البيانات

قد يبدأ العامل في التنفيذ قبل اعتماد المعاملة التي أنشأته. يوفّر Laravel إرسال المهام بعد الاعتماد، حتى لا تقرأ المهام سجلات غير معتمدة أو جرى التراجع عنها. في تطبيق Laravel 12، يبدو النمط الأساسي كما يلي:

DB::transaction(function () use ($validated) {
    $order = Order::create($validated);
    ProcessOrder::dispatch($order->id)->afterCommit();
});

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

صمّم المهام على أساس التنفيذ «مرة واحدة على الأقل»

افترض أن المهمة قد تُنفَّذ أكثر من مرة. احفظ مفتاح عدم التكرار، وسجّل العمليات المكتملة، واستخدم آلية عدم التكرار لدى المزوّد الخارجي إن وُجدت. لا تعتبر المهمة مكتملة قبل نجاح الأثر الخارجي. طابِق النتائج غير المؤكدة بدل تكرار عملية خصم أو شحن بشكل أعمى.

• حدّد مهلات الانتظار وحدود إعادة المحاولة وفترات التراجع التدريجي بحسب طبيعة كل عملية.
• اجعل مهلة العامل أقصر من فاصل إعادة المحاولة في الطابور، مع هامش للإيقاف، لتقليل المحاولات المتداخلة.
• راقب المهام الفاشلة وعمر الطابور؛ فالاستجابة HTTP 202 تعني «مقبول» وليس «مكتمل».
• أعد تشغيل العمّال طويلي التشغيل أثناء الإصدارات حتى يحمّلوا الشيفرة المقصودة.

تدرّب على الأعطال وعلى التراجع

اختبر وصول Webhook مكرر، وتعطّل عامل بعد استدعاء خارجي، وحالة جمود (Deadlock) في قاعدة البيانات، وتوقّف الطابور، وفشل عملية نشر. تحقّق من السجلات والآثار الجانبية الناتجة، وليس من استجابة HTTP وحدها. أضف آلية مطابقة للأعمال التي قُبلت لكنها لم تكتمل أبدًا.

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

المصادر وقراءات إضافية

• Laravel 12: الطوابير والإرسال بعد الاعتماد ومهلات الانتظار
• Laravel 12: معاملات قاعدة البيانات

تابع القراءة

قارن بين استراتيجيات العرض أو تواصل معنا بشأن الترحيل إلى Laravel.