التجارة السعودية · قدرة واجهات API

حدود طلبات سلة: طوابير عادلة قبل زيادة العمال

صمّم ميزانية طلبات مستقلة لكل متجر وطوابير عادلة لتكاملات سلة، مع إعادة محاولات مضبوطة ومعالجة الكتابات غير المحسومة وإظهار تقدم المزامنة.

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

يبدأ تاجر استيراد كتالوج كبير، وفي الوقت نفسه ينتظر تاجر آخر تحديث طلب واحد. العمليتان تمران بتطبيق التكامل نفسه، لكن لا ينبغي أن تنتظرا داخل طابور واحد بلا تمييز. زيادة عدد الـWorkers قد تزيد المشكلة: عمليات أكثر ترسل طلبات أكثر، من دون أن تزيد قدرة الخدمة الخارجية.

هذا مقال معماري معرفي، وليس إعلانًا عن ميزة جديدة في سلة. راجعت الوثائق الرسمية في ٣٠ سبتمبر ٢٠٢٦. التصميم التالي اقتراح لتنفيذه داخل تطبيقك، وليس خدمة جاهزة توفرها سلة تلقائيًا.

ابدأ من العقد الفعلي للواجهة

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

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

اضبط قبول الطلب قبل تنفيذه

تصميم مقترح هو إعطاء كل متجر طابورًا وميزانية قبول مشتركة بين العمليات. يحصل الـWorker على إذن قبل إرسال الطلب. ويجب تنسيق القرار بصورة ذرية؛ عداد داخل ذاكرة كل عملية لن يفرض حدًا مشتركًا على التطبيق كله.

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

لا تجعل متجرًا مشغولًا يؤخر الجميع

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

العدالة لا تعني معدلًا متساويًا لكل متجر، بل سياسة توزيع واضحة وحدًا مقبولًا للانتظار. لا تسمح لسيل غير محدود من المهام العاجلة بتجويع المطابقة إلى الأبد. راقب عمر أقدم مهمة مؤهلة، وليس عدد المهام في الطابور فقط.

القبول والعدالة وتأجيل المحاولات قرارات منفصلة؛ انتهاء مهلة الكتابة يحتاج تحققًا من النتيجة.
القبول والعدالة وتأجيل المحاولات قرارات منفصلة؛ انتهاء مهلة الكتابة يحتاج تحققًا من النتيجة. اضغط لعرض أكبر

أعد جدولة المهمة عند 429 بدل تعطيل العامل

عندما تقدم الاستجابة إرشادًا صالحًا لإعادة المحاولة، احفظ موعد السماح التالي وحرر الـWorker. لا تحجز العامل نائمًا طوال فترة انتظار طويلة. وإذا كانت الميزانية المتأثرة مشتركة، يجب أن ترى العمليات الأخرى فترة التهدئة نفسها، وإلا واصلت إرسال طلبات مرفوضة.

استخدم تراجعًا محدودًا مع توزيع عشوائي للانتظار عندما يناسب الحالة. يشرح مرجع AWS كيف يقلل Jitter تزامن المحاولات. طبّق الفكرة من دون الإرسال قبل الحد الأدنى الصحيح الذي يحدده المزود. ضع مهلة نهائية وعدد محاولات محدودًا كي لا تتحول المهمة إلى حلقة لا تنتهي.

انتهاء المهلة لا يحسم نتيجة الكتابة

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

مثلًا، إن كانت العملية تدعم مرجعًا خارجيًا موثقًا يمكن البحث به، فاستخدمه للتحقق. وإن لم يوجد استعلام موثوق، سجّل النتيجة غير المحسومة وأدخلها في مسار استعادة مضبوط. لا تفترض دعم Idempotency Headers من دون توثيق. يكمل ذلك دليل معالجة Webhooks بصورة موثوقة.

اجعل التأخير مفهومًا للتاجر

قبول المهمة الخلفية لا يعني اكتمال المزامنة. اعرض حالات منفصلة: في الانتظار، قيد التنفيذ، مؤجلة بسبب حدود المزود، مكتملة، وتحتاج تدخلًا. أظهر آخر وقت نجحت فيه المزامنة، واحتفظ بالتقدم عند إعادة المحاولة.

في المراقبة التشغيلية، ميّز بين تقييد المزود وتشبع نظامك. راقب عمر أقدم مهمة بحسب نوع العمل، وزمن الاكتمال، والمحاولات لكل عملية مكتملة، والكتابات غير المحسومة، والفشل النهائي. تجنب وضع معرّفات المتاجر داخل تسميات مقاييس غير محدودة؛ استخدم سجلات تشخيص مضبوطة الصلاحيات للتحقيق في متجر بعينه.

اختبر التعافي قبل زيادة عدد العمال

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

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

المراجع الرسمية

تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.

إعداد: Noor Yasser

من القرار إلى التنفيذ

تعمل على تحدٍ تقني مشابه؟

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

احجز لقاءً لمدة ٣٠ دقيقةالخدمة المرتبطةهندسة الأنظمة الخلفية وتكاملات APIمشروع من الأعمالمنصة اللوجستيات