رفتن به محتوای اصلی
بازگشت به وبلاگ

داده و اتصال فنی

Token Bucket؛ نرخ،جهش و اعتبارِ باقی‌مانده را جدا کنیم

Token Bucket را با نرخ۲ و ظرفیت۳ اجرا کنید؛ رد بدون مصرف،پرشدنِ نیم‌ثانیه،اشباع و۴۵کنترلِ کران روی زمانِ تزریق‌شده بررسی می‌شوند.

Token Bucket ظرفیتِ جهشِ کوتاه را از نرخِ پرشدنِ دوباره جدا می‌کند. یک سطل می‌تواند در لحظه چند واحد کار را بپذیرد،بعد برای برگشت اعتبار منتظر گذشتِ زمان بماند. این صفحه یک نمونهٔ strict با زمانِ کسریِ تزریق‌شده را اجرا می‌کند؛ هیچ API واقعی فراخوانی و هیچ سهمیه‌ای دور زده نمی‌شود.

نرخ۲،ظرفیت۳،شروعِ پر

واحدِ ما «واحد کار» و زمان بر حسب ثانیهٔ سپری‌شده است. سطل ابتدا۳اعتبار دارد و در هر ثانیه۲اعتبار برمی‌گردد،تا سقف۳. این token،توکنِ متنِ مدل زبانی نیست؛ برای استفادهٔ واقعی باید واحد و قراردادِ سرویسِ همان ارائه‌دهنده را جدا بخوانیم.

در زمان صفر،سه درخواستِ یک‌واحدی پذیرفته و اعتبار صفر می‌شود. چهارمی در همان لحظه رد می‌شود. ردشدن،اعتبار را منفی نمی‌کند و اعتبار تازه هم نمی‌سازد. اگر هر بار رد را با reset به ظرفیت کامل جواب بدهیم،محدودکننده عملاً بی‌معنا می‌شود.

قبل از تصمیم،پرشدنِ واقعی را حساب کنیم

available = min(capacity, old_tokens + rate * elapsed)
if cost <= available:
    tokens = available - cost
    accepted = True
else:
    tokens = available
    accepted = False

زمانِ آخرین بررسی نیز جلو می‌رود. اگر در یک‌چهارم ثانیه درخواست یک‌واحدی بیاید،فقط نیم‌واحد اعتبار داریم و رد می‌شود؛ همان نیم‌واحد حفظ می‌شود. در نیم‌ثانیه،نیم‌واحد دیگر اضافه و درخواستِ یک‌واحدی پذیرفته می‌شود. ردِ قبلی نباید آن نیم‌واحد را از بین برده باشد.

سکوتِ طولانی،ظرفیت بی‌نهایت نمی‌سازد

در زمان۱۰ثانیه،سطلِ مثال دوباره۳اعتبار دارد،نه مجموعِ بی‌حدِ همهٔ اعتبارهای نظریِ گذشته. یک درخواستِ سه‌واحدی پذیرفته و درخواستِ یک‌واحدیِ هم‌زمانِ بعدی رد می‌شود. این رفتارِ saturation همان سقف B در فرمول است.

دفترِ ۹ورود،زمان،هزینه،اعتبارِ قبلی،فاصلهٔ زمانی،اعتبارِ آماده و نتیجهٔ پذیرش را جدا ثبت می‌کند. Fraction برای زمان و اعتبارِ این داده‌هایِ کسری استفاده می‌شود تا نیم و یک‌چهارم با خطای نمایشیِ float اشتباه نشوند. خوابِ واقعی یا تغییرِ ساعتِ سیستم انجام نمی‌شود.

یک کران مستقل بر کارِ پذیرفته‌شده

در هر بازهٔ زمانی به طول dt،کارِ پذیرفته‌شده نباید از B+R×dt بیشتر شود. oracleِ فایل،تمام۴۵بازهٔ پیوستهٔ دفترِ ۹رخداد را بررسی می‌کند: مجموعِ هزینهٔ درخواست‌هایِ واقعاً پذیرفته را مستقل جمع می‌زند و با این کران می‌سنجد. رخدادهای هم‌زمان نیز با ترتیبِ مشخصِ دفتر باقی می‌مانند.

این کنترل،آزمایشِ همین trace است و جای اثباتِ همهٔ رفتارهای توزیع‌شده را نمی‌گیرد. صف،اجرای مؤخر،جبران خطا،ذخیرهٔ مشترک و مسابقهٔ دو پردازش در نمونه وجود ندارند. تابعِ تک‌فرایندی را محدودکنندهٔ نصب‌شدهٔ سرویس معرفی نمی‌کنیم.

ورودیِ ردشده را از درخواستِ محدودشده جدا کنیم

هزینهٔ مثبتِ بزرگ‌تر از ظرفیت،زمانِ عقب‌رونده،نرخِ صفر یا منفی،زمانِ بولین یاNaN و هزینهٔ صفر،در هفت آزمونِ ورودیِ نامعتبر رد می‌شوند. انتخابِ نرخِ مثبت،سیاستِ wrapperِ آموزشی ماست؛ نمی‌گوییم هر مدلِ سطل با نرخ صفر ذاتاً بی‌تعریف است. زمان و مقادیر نیز کران محلی دارند.

در مقابل،درخواستِ معتبرِ کم‌اعتبار،به‌عنوان accepted=false برمی‌گردد؛ این خطای قالب ورودی نیست. مخلوط‌کردنِ این دو وضعیت می‌تواند منطق retry را نادرست کند. صف و خطای۴۲۹ قراردادِ سرویس و انتظار را جدا توضیح می‌دهد و مهلت با ساعت monotonic بودجهٔ زمان را می‌سنجد. ادامه در مبانی هوش مصنوعی؛ این مثال نرخِ محصول اپرا یا سهمیهٔ هیچ API را اعلام نمی‌کند.

فایل تمرین و منبع

کد مستقلِ تمرین و کنترل‌ها؛ Python · ورودی‌ها و تمام خروجی واقعیِ همین تمرین؛ JSON

منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.

برای این نیاز، کدام خدمت مناسب‌تر است؟

تماس و منشی، چت سایت و تحلیل مکالمه سه مسیر متفاوت‌اند. ابتدا خدمت متناسب نیازتان را انتخاب کنید.

انتخاب میان سه خدمتراهنمای شروع با تیم اپرا

برآورد هزینه