المكاسب:
- يمكن تفسير حدود السرعة (RPM/ITPM/OTPM) و429 خطأ
- ينفذ التراجع الأسي وإعادة المحاولة مع إعادة المحاولة بعد
- يصنف رموز خطأ HTTP الشائعة ويعالجها بشكل صحيح (400/401/429/500/529)
في بيئة الإنتاج، لا تستجيب واجهة برمجة التطبيقات (API) بشكل مثالي طوال الوقت. في بعض الأحيان تقوم بإرسال الطلبات بسرعة كبيرة جدًا وتصل إلى الحد الأقصى؛ في بعض الأحيان يكون الخادم مشغولاً مؤقتًا؛ في بعض الأحيان يكون طلبك خاطئًا من البداية. ما يميز التكامل القوي عن محاولة الهواة هو أنه يتعامل مع هذه المواقف بشكل تنبؤي وتلقائي. ستتعرف في هذه الوحدة على حدود المعدل (RPM/ITPM/OTPM)، والخطأ 429، وإعادة المحاولة مع التراجع الأسي، والتصنيف المناسب لأكواد أخطاء HTTP الشائعة. الهدف: إنشاء تدفق قوي جدًا بحيث لن يلاحظه المستخدم أبدًا.
ما هي حدود السرعة؟
يحدد الموفر مقدار العمل الذي يمكن للمحول القيام به في فترة زمنية معينة. هذه الحماية؛ إنه يحمي البنية التحتية ويحميك من انفجارات التكلفة المفاجئة. هناك ثلاثة أنواع شائعة من الحدود:
- RPM (الطلبات في الدقيقة): عدد الطلبات في الدقيقة.
- ITPM (رموز الإدخال في الدقيقة): رمز الإدخال الذي يمكن معالجته في الدقيقة.
- OTPM (رموز الإخراج في الدقيقة): رمز الإخراج الذي يمكن إنتاجه في الدقيقة.
إذا تجاوزت أيًا من هذه الحدود، فسيرفض الموفر الطلب ويعيد رمز الخطأ 429. تختلف الحدود عمومًا وفقًا لمستوى حسابك (الطبقة) ويمكن زيادتها بمرور الوقت.
نصيحة: يمكنك مشاهدة اقترابك من الحد الأقصى من رؤوس الاستجابة. يقوم معظم مقدمي الخدمة بالإبلاغ عن حصتك المتبقية برؤوس مثل x-ratelimit-remaining-*. تعد مراقبة هذه القيم وخنق حركة المرور أمامك هي الطريقة الأكثر نضجًا لمنع المشكلة دون الحصول على 429.
429 والارتداد الأسي
429 (حد المعدل) هو خطأ مؤقت وقابل لإعادة المحاولة. الرد الصحيح هو انتظار الطلب لفترة ثم المحاولة مرة أخرى. لكن الانتظار المستمر لا يكفي؛ إذا حاول الجميع مرة أخرى في نفس الوقت، فسيتم الوصول إلى الحد الأقصى مرة أخرى. الحل هو التراجع الأسي: زيادة وقت الانتظار بشكل كبير مع كل محاولة فاشلة.
# تجربة منطق التراجع الأسي 1 → 429 → انتظر ثانية واحدة تجربة 2 → 429 → انتظر ثانيتين تجربة 3 → 429 → انتظر 4 ثوانٍ تجربة 4 → 429 → انتظر 8 ثوانٍ (+ "ارتعاش" عشوائي صغير)... استسلم وقم بالإبلاغ بعد تجارب N على الأكثر
تؤدي إضافة القليل من العشوائية (الارتعاش) إلى منع تصادم الطلبات عند محاولة إعادة المحاولة في نفس الوقت. بالإضافة إلى ذلك، غالبًا ما تحمل الاستجابة 429 رأسًا "إعادة المحاولة بعد": "حاول مرة أخرى خلال هذه الثواني العديدة". إن احترام هذا اللقب أدق من الانتظار الأعمى.
تنبيه: عندما تحصل على 429، فإن "إجبارها عن طريق إرسال المزيد من الطلبات" سيؤدي إلى تفاقم الوضع؛ يستمر ملء الحد ولا يتم تنفيذ أي طلبات. الرد الصحيح هو التراجع وليس التسارع. أخبار سارة: تقوم معظم حزم SDK الرسمية بإعادة المحاولة تلقائيًا لأخطاء 429 وأخطاء الخادم مع التراجع - استخدم سلوك SDK هذا قبل تثبيته يدويًا.
تصنيف رموز خطأ HTTP
ليس كل خطأ هو نفسه. التمييز الحاسم: هل يمكن إعادة المحاولة أم أنها مشكلة في الطلب/الهوية؟
الكود
معنى
هل يمكن تجربته مرة أخرى؟
الاستجابة الصحيحة
400
طلب غير صالح (خطأ في التنسيق/المعلمة)
لا
تصحيح الطلب؛ لا ترسل نفس مرة أخرى
401
خطأ في المصادقة (المفتاح غير صالح/مفقود)
لا
إصلاح المفتاح/العنوان
403
لا يوجد ترخيص (لا يمكن الوصول إلى النموذج/الميزة)
لا
تحقق من الأذونات/النطاق
404
لم يتم العثور على (معرف النموذج/نقطة النهاية غير صحيحة)
لا
معرف/عنوان النموذج الصحيح
429
تم تجاوز الحد الأقصى للسرعة
نعم
تراجع + إعادة المحاولة بعد ذلك
500
خطأ في الخادم
نعم
حاول مرة أخرى مع التراجع
529
الخادم مثقل
نعم
حاول مرة أخرى مع التراجع
القاعدة الذهبية: 429، 500، 529 مؤقتة؛ ويتم المحاولة مرة أخرى مع الانسحاب. 400، 401، 403، 404 هي مشكلات تتعلق بالطلب/الهوية؛ المحاولة مرة أخرى لن تحل المشكلة، وتضيع الجهد. يجب أن يميز الكود الخاص بك بين هاتين المجموعتين.
خطوة بخطوة: مكالمة دائمة
- تقديم الطلب. إذا نجحت، استمر.
- تصنيف رمز الخطأ. هل يمكن تجربته مرة أخرى؟
- إذا كان من الممكن المحاولة: اتبع إعادة المحاولة بعد ذلك، وقم بتطبيق التراجع الأسي + الارتعاش، وحاول عددًا محدودًا من المرات (على سبيل المثال، 5 مرات كحد أقصى).
- إذا لم تتم تجربتها: قم بإصلاح (التنسيق/المفتاح) والتوقف؛ لا تكرر نفس الطلب الخاطئ في الحلقة.
- فكر في الاستسلام. إذا لم ينجح الأمر بعد عدد n من المحاولات، فأظهر رسالة مهذبة للمستخدم وقم بتسجيل الحدث (وحدة التتبع 11).
# مكالمة قوية pseudo-codedene = 0repeat: Response = request_at() if Response.success: قم بإرجاع الاستجابة إذا كان Response.code في [429, 500, 529] وحاول < 5: wait = retry_after ?? (2^ حاول ثانية + غضب) Sleep(wait); حاول += 1؛ git مرة أخرى إذا كان رمز الاستجابة في [400، 401، 403، 404]: save_error(response); إرجاع "يجب إصلاح الطلب" إرجاع "خطأ دائم، حاول لاحقًا"
# تعليقات مهذبة للمستخدم (عند استنفاد عمليات إعادة المحاولة) "أنا مشغول الآن، ولم أتمكن من معالجة طلبك. حاول مرة أخرى قريبًا، وإلا قمت بحفظ طلبك، وسأعود إليك عندما يصبح جاهزًا."
موجه ضعيف/موجه قوي (هنا: تصميم رسالة الخطأ)
# ضعيف (يعرض خطأ أوليًا للمستخدم)"خطأ 429: معدل_الحد_خطأ"
# قوي (سهل الاستخدام، مطمئن، يقترح إجراءات) "كان هناك ازدحام مؤقت في النظام. لقد تلقينا طلبك بأمان ويتم تجربته مرة أخرى تلقائيًا. إذا لم تظهر النتيجة خلال بضع ثوانٍ، يمكنك تحديث الصفحة."
إن الكشف عن الخطأ الفني الخام للمستخدم النهائي يؤدي إلى تقويض الثقة ويمكن أن يشكل ثغرة أمنية. تصنيف الأخطاء داخليًا ومنح المستخدم رسالة هادئة وموجهة نحو العمل؛ فقط اكتب التفاصيل الفنية للسجل.
ثلاث حالات صغيرة
الحالة 1 - تحطم القارب في انفجار مروري. تلقى روبوت خدمة العملاء 429 حركة مرور متزايدة في يوم الحملة؛ لم تكن هناك إعادة محاولة في الكود، فكل خطأ كان ينعكس مباشرة على المستخدم باعتباره "خطأ". لقد أضافوا الارتداد الأسي + إعادة المحاولة بعد؛ مع نفس حركة المرور، تم تمرير الطلبات مع تأخير لعدة ثوان، ولم ير المستخدم أي أخطاء.
الحالة 2 - تجربة 400 في الحلقة. كان التكامل يحصل على 404 بسبب معرف نموذج غير صالح، ولكنه كان يتعامل مع جميع الأخطاء على أنها "عابرة" ويحاول مرة أخرى في حلقة لا نهائية؛ أصبح السجل منتفخًا وتم إنشاء حمل غير ضروري. أضافوا تصنيف الخطأ: 404 يعتبر دائمًا، وتم إيقاف الحلقة وتصحيح معرف النموذج. الدرس المستفاد: لا تجرب كل خطأ مرة أخرى.
الحالة 3 - إدارة الحد من الأمام. كانت مهمة إثراء البيانات تعمل باستمرار عند الحد الأقصى البالغ 429. لقد اتبعوا الرأس المتبقي لـ x-ratelimit وقاموا باختناق حركة المرور وفقًا للحصة. لذلك حافظوا على وتيرة ثابتة أقل بقليل من الحد الأقصى، دون أخذ أي 429 ثانية؛ تم إنجاز المهمة بشكل أكثر توقعًا وأسرع.
الأخطاء الشائعة
- زيادة السرعة في 429: تزيد الحالة سوءاً؛ التبديل إلى التراجع.
- إعادة محاولة كل خطأ: 400/401/404 دائم؛ المحاولة مرة أخرى هي مضيعة.
- استخدام الانتظار الثابت: إنشاء تصادم؛ استخدم الأسي + غضب.
- تجاهل "إعادة المحاولة بعد": من الأكثر دقة الالتزام بالوقت المحدد من قبل الموفر.
- الكشف عن الخطأ الأولي للمستخدم: يهز الثقة، ويخلق نقاط ضعف؛ تصنيف داخل.
- عدد مرات إعادة المحاولة غير المحدودة: قم بتعيين حد أعلى (على سبيل المثال، 5 مرات إعادة محاولة)؛ ثم استسلم برشاقة.
أعمق: قائمة الانتظار، والتزامن، وقواطع الدائرة
إن تحمل الرغبة الواحدة هو الخطوة الأولى؛ النضج الحقيقي هو إدارة عدد كبير من الطلبات دون تجاوز الحدود. هناك ثلاثة مفاهيم تلعب دورها هنا.
قائمة الانتظار: يمكنك وضع الطلبات في قائمة انتظار لإرسالها بوتيرة متحكم فيها بدلاً من إرسالها على الفور. تعمل قائمة الانتظار على تسهيل الاندفاعات المفاجئة لحركة المرور: حتى لو وصل 1000 طلب مرة واحدة، فإن قائمة الانتظار ستحررها بمعدل أقل من الحد. بهذه الطريقة تمنع 429، فلا داعي للقلق بشأن إصلاحه.
حد التزامن: يمكنك تحديد عدد الطلبات "الموجودة" في نفس الوقت. الطلبات المتوازية غير المحدودة تملأ حدود RPM وTPM بسرعة. إن سقف التزامن المعقول (على سبيل المثال لا يزيد عن 10 طلبات متزامنة) يحافظ على الحدود ويجعل النظام قابلاً للتنبؤ به.
قاطع الدائرة: إذا استمر المزود في إعادة 500/529، فبدلاً من محاولة كل طلب بإصرار، فإنك "تقطع الدائرة" لفترة من الوقت وتفشل الطلب بسرعة دون إرساله على الإطلاق. بعد الانتظار، يمكنك تشغيل الدائرة مرة أخرى والمحاولة. يمنع هذا النمط نظامك من التعطل في حالة فشل الموفر المؤقت.
يعمل هؤلاء الثلاثة معًا على إنشاء مرونة على مستوى النظام تتجاوز منطق إعادة المحاولة لمكالمة واحدة. على نطاق صغير، تكون إعادة المحاولة التلقائية لـ SDK كافية؛ مع نمو الحجم، أصبح الانتظار، والتزامن، وقواطع الدائرة الكهربائية أمرًا لا غنى عنه. جميعها لها نفس الهدف المشترك: عرض مشكلة مؤقتة للمستخدم ليس على شكل عطل، ولكن على شكل تأخير غير مرئي لبضع ثوان.
باختصار
429 يتم إرجاعه عند تجاوز حدود السرعة (RPM/ITPM/OTPM)؛ يعد هذا خطأ مؤقتًا وستتم إعادة المحاولة باستخدام إعادة المحاولة والتراجع الأسي + الارتعاش. 500 و529 مؤقتة أيضًا؛ 400/401/403/404 هي مشكلة طلب/هوية ولا يمكن حلها عن طريق المحاولة مرة أخرى. يفصل التدفق القوي الأخطاء إلى هاتين المجموعتين، ويحاول عددًا محدودًا من المرات، ويراقب الحد من الأمام ويظهر رسائل تهدئة للمستخدم.
مهمة التطبيق
النظر في التكامل الخاص بك. (1) قم بإدراج رموز الخطأ التي قد تواجهها وفصلها إلى "قابلة لإعادة المحاولة / دائمة". (2) قم بتدوين خطة التراجع الأسية الخاصة بك (الانتظار الأولي، المعامل، الحد الأقصى، الارتعاش). (3) حدد كيفية استخدام رأس إعادة المحاولة بعد. (4) اكتب الرسالة المهذبة التي سيتم عرضها للمستخدم عند استنفاد المحاولات.
قائمة مرجعية
- [ ] يمكنني شرح حدود RPM/ITPM/OTPM و429.
- [ ] يمكنني تطبيق منطق التراجع الأسي + الارتعاش + إعادة المحاولة بعد ذلك.
- [ ] يمكنني تصنيف رموز الأخطاء على أنها قابلة لإعادة المحاولة/دائمة.
- [ ] أعلم أنه لا ينبغي لنا أن نجرب كل خطأ.
- [ ] بدلاً من الخطأ الفادح، يمكنني أن أظهر للمستخدم رسالة هادئة وموجهة نحو العمل.