توسيع توليد الصور: الطوابير وidempotency وإعادة المحاولة

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

الطابور هو التصميم

الغريزة الأولى هي استدعاء الـ API مباشرةً من معالج الطلب. ينجح ذلك في بيئة التطوير ويفشل أول مرة تصل فيها حركة حقيقية، لأنه لا شيء يفصل الطلب عن السعة: تتحول الذروة إلى جدار من انتهاءات المهلة، ولا يبقى سجل لما كان جاريًا حين أُعيد تشغيل العملية.

ضع طابورًا دائمًا في الوسط. و«دائم» هي الكلمة المفتاحية — فالقائمة في الذاكرة تفقد كل مهمة جارية عند النشر، والنشر يحدث أثناء الحركة. جدول في قاعدة البيانات يفي بالغرض تمامًا عند هذا الحجم، ويمنحك سجلًا قابلًا للاستعادة للحالة كأثر جانبي.

الضغط العكسي ميزة لا عيب

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

Idempotency والإخفاق الملتبس

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

يحلّ مفتاح idempotency هذا بجعل إعادة المحاولة آمنة: المفتاح نفسه يُرجع المهمة الأصلية بدل إنشاء ثانية. القواعد بسيطة ويسهل الخطأ فيها — أنشئ المفتاح حين يتصرّف المستخدم لا حين يُجرى استدعاء HTTP؛ واحفظه مع سجل المهمة؛ وأعد استخدامه في كل محاولة إعادة لذلك الفعل.

# المفتاح نفسه لكل إعادة محاولة لفعل واحد من المستخدم
KEY=$(uuidgen)
curl -X POST https://api.example/api/v1/jobs \
  -H "X-API-Key: $API_KEY" -H "Idempotency-Key: $KEY" \
  -F image=@photo.jpg -F feature=undress -F consent=confirmed

ما لا ينبغي إعادة محاولته تلقائيًا

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

التسوية: الحلقة التي تنقذك

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

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

عرض التقدّم دون إرهاق قاعدة البيانات

يبثّ التوليد تقدّمًا بوتيرة عالية — ربما عدة مرات في الثانية لكل مهمة. وكتابة كل نبضة إلى قاعدة بياناتك تضاعف حمل الكتابة دون معلومة إضافية. قيّد الحفظ الدائم إلى نحو مرة واحدة في الثانية مع كتابة الحالة النهائية دائمًا، ثم بثّ القيم الحيّة إلى العملاء المتصلين دون المساس بالتخزين إطلاقًا.

قائمة تحقّق تصمد

• طابور دائم بين المستخدمين والـ API، قابل للاستعادة بعد إعادة التشغيل.
• حدّ صريح للمهام الجارية، مُنفَّذ في مكان واحد.
• مفتاح idempotency يُنشأ لكل فعل من المستخدم، ويُحفظ، ويُعاد استخدامه عند إعادة المحاولة.
• إخفاقات الإرسال الملتبسة تُعلَّم للمراجعة بدل إعادة المحاولة التلقائية.
• حلقة تسوية تُقارِب الحالة بصرف النظر عن الأحداث الفائتة.
• كتابات تقدّم مقيّدة الوتيرة، مع بثّ التقدّم الحيّ عبر الـ socket.

لا شيء من هذا خاص بتوليد الصور — إنها نظافة اعتيادية للأنظمة الموزّعة. لكنها تصبح مرئية هنا، لأن كل وحدة عمل بطيئة وباهظة بما يكفي لتتوقف الاختصارات المعتادة عن كونها غير مرئية.

الأسئلة الشائعة