سود:
- می تواند محدودیت های سرعت (RPM/ITPM/OTPM) و خطاهای 429 را تفسیر کند
- اجرای عقب نشینی نمایی و تلاش مجدد با تکرار-پس از آن
- کدهای خطای رایج HTTP را به درستی طبقه بندی و مدیریت می کند (400/401/429/500/529)
در یک محیط تولید، هیچ API همیشه به طور کامل پاسخ نمی دهد. گاهی اوقات شما درخواست ها را خیلی سریع ارسال می کنید و به حد مجاز می رسید. گاهی اوقات سرور به طور موقت مشغول است. گاهی اوقات درخواست شما از ابتدا اشتباه است. چیزی که یک ادغام جامد را از یک تلاش آماتور متمایز می کند این است که این موقعیت ها را به طور پیش بینی و خودکار مدیریت می کند. در این بخش با محدودیت های نرخ (RPM/ITPM/OTPM)، خطای 429، تلاش مجدد با عقب نشینی نمایی و طبقه بندی مناسب کدهای خطای رایج HTTP آشنا خواهید شد. هدف: ایجاد جریانی که آنقدر قوی باشد که کاربر هرگز متوجه آن نشود.
محدودیت سرعت چیست؟
ارائه دهنده میزان کاری که یک سوئیچ می تواند در یک دوره زمانی معین انجام دهد را محدود می کند. این حفاظت؛ هم از زیرساخت ها و هم از شما در برابر انفجار هزینه های ناگهانی محافظت می کند. سه نوع معمول محدودیت وجود دارد:
- RPM (درخواست در دقیقه): تعداد درخواست در دقیقه.
- ITPM (توکن های ورودی در دقیقه): نشانه ورودی که می تواند در دقیقه پردازش شود.
- OTPM (Output Tokens Per Minute): نشانه خروجی که می تواند در دقیقه تولید شود.
اگر از هر یک از این محدودیت ها تجاوز کنید، ارائه دهنده درخواست را رد کرده و کد خطای 429 را برمی گرداند. محدودیت ها به طور کلی بسته به سطح حساب شما (سطح) متفاوت است و ممکن است در طول زمان افزایش یابد.
نکته: وقتی به حد مجاز نزدیک میشوید، میتوانید از سرصفحههای پاسخ تماشا کنید. اکثر ارائه دهندگان سهمیه باقی مانده شما را با سرصفحه هایی مانند x-ratelimit-remaining-* گزارش می دهند. نظارت بر این مقادیر و کاهش ترافیک جلویی بالغ ترین راه برای جلوگیری از مشکل بدون دریافت 429 است.
429 و عقب نشینی نمایی
429 (محدودیت نرخ) یک خطای موقت و قابل امتحان مجدد است. پاسخ صحیح این است که مدتی منتظر درخواست باشید و دوباره امتحان کنید. اما یک انتظار مداوم کافی نیست. اگر همه به طور همزمان دوباره تلاش کنند، دوباره به حد مجاز می رسد. راه حل عقب نشینی نمایی است: افزایش زمان انتظار به صورت تصاعدی با هر تلاش ناموفق.
# آزمایش منطقی عقب نشینی نمایی 1 ← 429 ← آزمایش 1 ثانیه صبر کنید 2 ← 429 ← آزمایش 2 ثانیه صبر کنید 3 ← 429 ← آزمایش 4 ثانیه صبر کنید 4 ← 429 → 8 ثانیه صبر کنید (+ "جستر" تصادفی کوچک)... تسلیم شوید و حداکثر پس از 1 بار آزمایش گزارش دهید
افزودن کمی تصادفی (جتر) به این امر از برخورد درخواست ها هنگام تلاش برای تلاش مجدد در همان زمان جلوگیری می کند. بعلاوه، پاسخ 429 اغلب دارای یک سرصفحه «تکرار مجدد بعد از» است: «در این چند ثانیه دوباره امتحان کنید». احترام به این عنوان دقیق تر از انتظار کورکورانه است.
احتیاط: وقتی یک 429 دریافت می کنید، "اجبار کردن آن با ارسال درخواست های بیشتر" وضعیت را بدتر می کند. محدودیت همچنان پر می شود و هیچ درخواستی انجام نمی شود. پاسخ صحیح عقب نشینی است نه شتاب. خبر خوب: اکثر SDK های رسمی به طور خودکار 429 را دوباره امتحان می کنند و خطاهای سرور با عقب نشینی - از این رفتار SDK قبل از نصب دستی آن استفاده کنید.
طبقه بندی کدهای خطای HTTP
هر اشتباهی یکسان نیست. تمایز انتقادی: آیا می توان آن را دوباره امتحان کرد یا یک مسئله درخواست/هویت است؟
کد
معنی
میشه دوباره امتحان کرد؟
پاسخ صحیح
400
درخواست نامعتبر (خطای قالب/پارامتر)
نه
اصلاح درخواست؛ دوباره همان را ارسال نکنید
401
خطای احراز هویت (کلید نامعتبر/فقدان)
نه
رفع کلید/عنوان
403
بدون مجوز (بدون دسترسی به مدل/ویژگی)
نه
مجوزها/حوزه را بررسی کنید
404
یافت نشد (شناسه مدل/نقطه پایانی نادرست)
نه
شناسه/آدرس مدل صحیح
429
از حد مجاز سرعت فراتر رفت
بله
عقب نشینی + تلاش مجدد - بعد
500
خطای سرور
بله
با Retreat دوباره امتحان کنید
529
سرور بیش از حد بارگذاری شده است
بله
با Retreat دوباره امتحان کنید
قانون طلایی: 429، 500 و 529 موقتی هستند. با انصراف دوباره امتحان می شود. 400، 401، 403، 404 مسائل مربوط به درخواست/هویت هستند. تلاش مجدد آن را حل نمی کند و تلاش را هدر می دهد. کد شما باید بین این دو گروه تمایز قائل شود.
گام به گام: تماس بادوام
- درخواست را ارسال کنید. در صورت موفقیت، ادامه دهید.
- کد خطا را طبقه بندی کنید میشه دوباره امتحان کرد؟
- اگر قابل امتحان است: سعی مجدد را دنبال کنید، پس از حرکت نمایی + جیتر را اعمال کنید، تعداد محدودی بار امتحان کنید (مثلاً حداکثر 5).
- اگر امتحان نشد: رفع (فرمت/کلید) و توقف. همان درخواست اشتباه را در حلقه تکرار نکنید.
- تسلیم شدن را در نظر بگیرید. اگر بعد از n تلاش موفق نشدید، یک پیام مودبانه به کاربر نشان دهید و رویداد را ثبت کنید (واحد پیگیری 11).
# فراخوانی قوی شبه کدده = 0repeat: answer = request_at() if answer.success: پاسخ را اگر answer.code در [429, 500, 529] برگردانید و < 5: wait = retry_after ?? (2^sec + jitter) sleep(wait); سعی کنید += 1; دوباره git اگر answer.code در [400, 401, 403, 404]: save_error(response); بازگشت "درخواست باید رفع شود" بازگشت "خطای دائمی، بعدا امتحان کنید"
# بازخورد مودبانه به کاربر (وقتی تلاش های مجدد تمام شد) "در حال حاضر مشغول هستم، نتوانستم درخواست شما را پردازش کنم. به زودی دوباره امتحان کنید، یا درخواست شما را ذخیره کردم، وقتی آماده شد با شما تماس خواهم گرفت."
اعلان ضعیف / اعلان قوی (اینجا: طراحی پیام خطا)
# WEAK (خطای خام را به کاربر نشان می دهد) "خطای 429: rate_limit_error"
# STRONG (کاربر پسند، اطمینان بخش، پیشنهاد اقدام) "یک شلوغی موقتی در سیستم وجود داشت. ما درخواست شما را با خیال راحت دریافت کردیم و دوباره به طور خودکار امتحان می شود. اگر نتیجه در عرض چند ثانیه ظاهر نشد، می توانید صفحه را بازخوانی کنید."
فاش کردن خطای فنی خام برای کاربر نهایی هم اعتماد را تضعیف می کند و هم می تواند یک آسیب پذیری امنیتی باشد. خطاها را به صورت داخلی دسته بندی کنید و به کاربر پیامی آرام و عمل محور بدهید. فقط جزئیات فنی را برای ثبت بنویسید.
سه کیف کوچک
مورد 1 - قایق در انفجار ترافیک سقوط کرد. یک ربات خدمات مشتری 429 ترافیک در روز کمپین دریافت کرد. هیچ تلاش مجددی در کد وجود نداشت، هر خطا مستقیماً به عنوان یک "خطا" به کاربر منعکس می شد. آنها اصلاح نمایی + تلاش مجدد- بعد را اضافه کردند. با همین ترافیک، درخواست ها با چند ثانیه تاخیر ارسال شد، کاربر هیچ خطایی ندید.
مورد 2 - تلاش 400 در حلقه. یک ادغام به دلیل شناسه مدل نامعتبر، 404 دریافت می کرد، اما همه خطاها را به عنوان "گذرا" تلقی می کرد و دوباره در یک حلقه بی نهایت تلاش می کرد. ورود به سیستم متورم شد و بار غیر ضروری ایجاد شد. آنها طبقه بندی خطا را اضافه کردند: 404 دائمی در نظر گرفته می شود، حلقه متوقف می شود و شناسه مدل تصحیح می شود. درس: هر اشتباهی را دوباره تکرار نکنید.
مورد 3 - مدیریت محدودیت از جلو. یک کار غنی سازی داده به طور مداوم در حد 429 در حال اجرا بود. آنها هدر x-ratelimit-remaining را دنبال کردند و طبق سهمیه ترافیک را مهار کردند. بنابراین آنها یک سرعت ثابت را درست زیر حد مجاز، بدون گرفتن هیچ 429s حفظ کردند. کار با پیش بینی بیشتر و سریعتر انجام شد.
اشتباهات رایج
- افزایش سرعت در 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 را توضیح دهم.
- [ ] من می توانم منطق عقب نشینی نمایی + جیتر + تلاش مجدد- بعد را اعمال کنم.
- [ ] می توانم کدهای خطا را به عنوان قابل امتحان مجدد/دائمی طبقه بندی کنم.
- [ ] می دانم که نباید هر اشتباهی را امتحان کنیم.
- [ ] به جای یک خطای خام، می توانم پیامی آرام و کنش محور را به کاربر نشان دهم.