رستوران شیک دم در یک میزبان دارد. هر میز در هر ساعت فقط چند مهمان میپذیرد. اگر یک گروه عجول — یا یک اپ باگدار — بخواهد هر دقیقه ده بار بیاید، میزبان میگوید «الان جا نیست؛ بیست دقیقه دیگر بیا». در وب به این سقف میگویند Rate Limiting. جواب رد معمولاً 429 است، با هدر Retry-After.
شغل Rate Limiter این است که هر کلاینت در هر بازه چند درخواست حق دارد. سپر است برابر سوءاستفاده، باگ کلاینت، و صورتحساب سرسامآور ابر. بدون آن، یک اپ خراب کل فروشگاه را میخواباند.
چهار الگوریتم، چهار شغل
همه «سقف میگذارند». فرقشان این است Burst کوتاه را راه میدهند یا له میکنند، و در مرز پنجره دروغ میگویند یا نه.
| الگوریتم | ایده | نکته |
|---|---|---|
| Token Bucket | سطلی که با نرخ ثابت پر میشود؛ هر درخواست یک ژتون میخرد | اجازه Burst کوتاه + نرخ میانگین کنترلشده؛ محبوبترین |
| Leaky Bucket | خروجی با نرخ ثابت چکه میکند | خروجی صاف؛ Burst را له میکند |
| Fixed Window | شمارنده هر پنجره — مثلاً هر دقیقه | ساده؛ در مرز پنجرهها تا ۲ برابر حد رد میشود |
| Sliding Window | پنجره روی زمان میلغزد — لاگ یا تقریب وزنی | دقیقتر، کمی گرانتر |
وقتی چند سرور داری
اگر هر Server شمارنده خودش را داشته باشد، سقف دروغ است: ده سرور یعنی ده برابر حد. شمارنده باید مشترک باشد — معمولاً Redis با اسکریپت اتمی Lua که «بخوان، کم کن، جواب بده» را یکجا انجام میدهد تا race نشود.
- کلید شمارش را لایهلایه بگذار: per-user ،per-IP ،per-API-key — و یک سقف کلی برای کل سیستم.
- همیشه هدر بده: X-RateLimit-Limit ،X-RateLimit-Remaining ،Retry-After. کلاینت خوب خودش عقب مینشیند.
- در لبه اعمال کن — API Gateway — نه در عمق سیستم. درخواست ردشده نباید CPU و DB بسوزاند.
- برای مهمان سختگیر، برای مشتری پولی سخاوتمند. Limit بخشی از مدل تجاری است، نه فقط دفاع فنی.
به زبان ساده
میزبان دم در ژتون میدهد؛ اگر سطل خالی شد میگوید بعداً بیا. همان Rate Limiting و پاسخ 429.
مثال واقعی
اپ باگدار هزار درخواست در ثانیه میفرستد؛ Gateway با سقف per-API-key جلویش را میگیرد تا بقیه آسیب نبینند.