فنی · پاسخ مستند
تلاش مجدد با exponential backoff
تلاش مجدد با exponential backoff یک راهبرد مدیریت خطاست که در آن فاصله میان تلاش‌های مجدد پیاپی برای یک عملیات ناموفق به‌صورت نمایی افزایش مییابد. به‌جای تلاش مجدد در فواصل ثابت، سیستم پس از هر شکست مدت بیشتری صبر میکند تا سرور گیرنده فرصت داشته باشد از ازدحام یا قطعی موقت بازیابی شود.
سازوکار عملکرد
فرایند با یک زمان انتظار اولیه، مثلاً یک ثانیه، شروع میشود. اگر اولین تلاش مجدد شکست بخورد، زمان انتظار در یک ضریب ثابت، معمولاً دو، ضرب میشود. تلاش مجدد دوم پس از دو ثانیه، سومی پس از چهار ثانیه، چهارمی پس از هشت ثانیه و به همین ترتیب انجام میشود. این تصاعد هندسی تا رسیدن به سقف حداکثر تأخیر یا حداکثر تعداد تلاش‌ها ادامه پیدا میکند و در آن نقطه پیام به‌عنوان شکست دائمی علامت می‌خورد.
اهمیت برای فرستندگان
این روش مانع میشود فرستنده ناخواسته یک حمله منع سرویس (Denial of Service) علیه سرور ایمیل گیرنده انجام دهد. اگر هزاران پیام همزمان شکست بخورند و همه هر ده ثانیه یک بار دوباره تلاش کنند، جهش ترافیکی حاصل می‌تواند سرور گیرنده را از دسترس خارج نگه دارد. فرستندگان با پخش کردن تلاش‌های مجدد در طول زمان، اعتبار بهتری حفظ می‌کنند و احتمال اینکه خطای موقت 4xx در SMTP پیش از حذف پیام برطرف شود افزایش مییابد.
ملاحظات عملیاتی
یک افزوده مهم به این راهبرد jitter است که مقدار کمی نویز تصادفی به تأخیر اضافه میکند. بدون jitter، درخواست‌های ناموفقی که همزمان رخ داده‌اند در موج‌های هماهنگ دوباره تلاش می‌کنند و جهشهای ترافیکی ایجاد می‌کنند. پیاده‌سازی jitter تضمین میکند تلاش‌های مجدد به‌طور یکنواخت در بازه زمانی پخش شوند و فشار بر زیرساخت بیشتر کاهش یابد.
اشتباهات رایج در پیاده‌سازی
توسعه‌دهندگان اغلب فراموش می‌کنند سقفی برای تعداد تلاش‌های مجدد یا مقدار تأخیر تعیین کنند. بدون سقف، زمان انتظار می‌تواند به چند ساعت یا چند روز برسد و برای ایمیل‌های تراکنشی تأخیر غیرقابل‌قبولی ایجاد کند. اشتباه دیگر، قابل‌تلاش‌مجدد دانستن شکست‌های دائمی 5xx است؛ exponential backoff فقط باید برای خطاهای گذرای 4xx، مانند محدودیت نرخ (rate limit) یا greylisting موقت، به کار رود.
نمونه عملی
یک ایمیل تراکنشی را در نظر بگیرید که از طریق API ارسال میشود. تلاش 1 به دلیل خطای 421 (سرور مشغول) شکست می‌خورد. سیستم 2 ثانیه صبر میکند. تلاش 2 شکست می‌خورد؛ سیستم 4 ثانیه صبر میکند. تلاش 3 شکست می‌خورد؛ سیستم 8 ثانیه صبر میکند. تا زمان تلاش 4، سرور گیرنده احتمالاً صف خود را خالی کرده و ایمیل پذیرفته میشود. SendHQ ابزارهای رایگانی در https://sendhq.cc/tools ارائه می‌دهد که به مدیریت کارایی زیرساخت ایمیل کمک می‌کنند.
پرسش‌هایی که تیم‌ها می‌پرسند
تفاوت backoff ثابت و exponential backoff چیست؟
در backoff ثابت، صرفنظر از تعداد شکستها، هر X ثانیه یک بار دوباره تلاش میشود. در exponential backoff فاصله پس از هر شکست افزایش مییابد تا بار روی سرور مقصد کم شود.
چه زمانی باید تلاش مجدد را متوقف کرد؟
تلاش مجدد باید زمانی متوقف شود که یک شکست دائمی 5xx برگردد، به حداکثر تعداد تلاش‌ها برسید یا به سقف حداکثر تأخیر برسید.
آیا jitter بر رشد نمایی اثر میگذارد؟
خیر، jitter یک جابهجایی تصادفی به تأخیر نمایی محاسبهشده اضافه میکند تا از جهشهای هماهنگ تلاش مجدد میان چند درخواست همزمان جلوگیری شود.
منابع اصلی
- RFC 5321: پروتکل ساده انتقال ایمیل (SMTP) — RFC Editor
- بهترین شیوه‌های رایج M3AAWG — M3AAWG