מגבלות קצב עיצוב

1) מדוע קצב מגביל

קצב ההגבלה מגן על הזמינות והכלכלה של API: עצירת שיטפונות, התפרצויות של מגשים חוזרים, מילוי נושים, מגן על פעולות יקרות (עסקאות כספים, דור דיווח), מחליק את העומס על מערכות תלויות (בסיסי נתונים/ספקי נתונים). עיצוב טוב מעניק הגינות, יכולת חיזוי של איחוי וברור.

מטרות מפתח

יציבות RPS והגנת עומס גיבוי.
”גמישות מבוקרת” (קצבת פרץ).
הפרדת לקוחות (per-user/per-organization/per-key/per-IP/per-region).
מודל ערך: ”מחירים” שונים עבור עסקאות שונות.

2) סוגי הגבלה

הגבלת RPS: בקשות לשנייה/דקה.
מכסות: תקציב כולל לתקופה (יום/חודש).
תחרותיות: פעולות סימולטניות (קופה, עבודה כבדה).
קצב/פס Bytes/sec (טעינה/פריקה).
גבולות משוקללים: ”עלות” הבקשה על ידי מורכבות (למשל, מורכבות GraphQL, גודל אצווה).
אדפטיבי: מהודק במקרה של חריגות (פעילות חשודה/שגיאות 401/403/5xx).

3) אלגוריתמים ומתי ליישם אותם

3. 1 דלפק חלונות קבוע

פשוט: נגד לכל מרווח (למשל. 100 r/min).
מקצוענים: עלות מינימלית. חסרונות: ”פרץ קצה” בגבולות החלון.

לוחות ניהול, דיוק נמוך, עלות נמוכה.

3. 2 חלון הזזה (רישום/מונה)

מחסומי זמן של בקשות אחרונות, מדויקים, יקרים בזיכרון.
נגד: ממוצע של שני חלונות סמוכים (גלגול), פשרה של דיוק ומחיר.

כאשר: API ציבורי של תנועה בינונית, אתה צריך שייק ללא מתמטיקה מורכבת.

3. 3 דלי טוקן

פרמטרים: שיעור 'r' (אסימונים/שניות) וקיבולת 'b' (פרץ). כל בקשה ”שורף” האסימון.
יתרונות: קצבת פרץ טבעית, יישום פשוט. חסרונות: אין ערנות קפדנית.

כאשר: כמעט תמיד עבור RPS, אם ”צחוקים” נחוצים בתוך 'b'.

3. 4 דלי דולף (טפטוף)

תור שממנו ”דולף” במהירות קבועה.
מקצוענים: אפילו זרימת פלט. עוד עיכובים.

כאשר: החלקה לספקים ”שבריריים” חיצוניים.

3. 5 GCRA (אלגוריתם קצב תא כללי)

• 'TAT _ next = max (TAT_current, עכשיו) + 1/r', הבקשה מתקבלת אם 'עכשיו <= TAT_current + פרץ/r'.
• מקצוענים: מחמיר, מדויק, זיכרון קטן (לשמור TAT על ידי מפתח). אסירים: קשה יותר להבין.

כאשר: צריך שליטה קפדנית וחלקות, גבולות מבוזרים.

3. 6 סמאפורות תחרותיות

דלפק פעולה פעיל; כניסה - אם יש ”כרטיסים”; יציאה - שחרור.
מבצעים ארוכי טווח, חוטים, שקע אינטרנט, הורדות.

4) הגבלת מודל מפתח

• 'client _ id'/' api _ key '/' user _ id '/' org _ id&pose
• ”IP/ASN/geo” (הגנה גסה)
• 'אנדפוינט/שיטה' (מסלולים חמים)
• ”scope/plan/tier” (רוטיזציה)
• 'idempotency _ key' (פעולות כתיבה)
• השתמש בהיררכיה: קודם קפדני לכל מפתח, אחר כך לכל ארגון, ואז גלובלי.

5) מודל עלות

• GraphQL: סיבוכיות שדה x עומק.
• מנוחה: גודל תגובה/בקשה, סוג פעולה (קרא = 1, כתוב = 3, דו "ח = 10).
• אצווה: ”עלות = min (n, cap)”.
• אנחנו מגבילים אסימונים, לא ”בקשות”: ”תקציב - = עלות (q)”.

6) יישום מבוזר

6. 1 כספות

בתהליך: מהיר ביותר, אבל לא גבול כללי (מתאים למגבלות ”רכות” מקומיות).
רדיס: דה פקטו סטנדרטי. INCR/EXPIRE, תסריטי LUA (אטומיציה), ZSET עבור חלון הזזה, מפתחות עם TTL.
שליח/NGINX/Kong/Traefik: מסננים מובנים; נוח למתחם.
שירות Mesh: גבולות מקומיים על סירה + סינכרון גלובלי.

6. 2 אטומיות ומרוץ

לואה ברדיס: בודק ומצטבר בצעד אחד.
GCRA: לאחסן TAT אחד עם CAS/script.
עקביות השעון: NTP, טיימרים מונוטוניים.
שארדינג: חשיש עקבי על ידי מפתח; להימנע מחתיכות ”חמות”.

6. 3 הפצה של Geo

גבולות מקומיים על אשכולות אזוריים + עליונים גלובליים (גסים).
CRDT/שכפול - זהירות (עיכובים, צריכה כפולה). גבולות אזוריים עם מרווח עדיפים.

7) מדיניות ותעדוף

תוכניות: Free/Pro/Enterprise עם 'r' שונה, 'b', מכסות.
סדר עדיפויות: מסלולים ”יקרים” מקבלים פחות הגבלה או יותר עלות.
רשימות: אפשר רשימה לאינטגרציה, הכחיש על ידי ASN/proxy/TOP.
הסלמה: אם אתה עולה על זה שוב, תוריד את הגבול, הכנס הוכחת עבודה/קפטצ 'ה/אתגרים.

8) דוגמאות של תצורות

8. שליח 1 (מסנן הגבלת קצב HTTP, פסאודו)

yaml rate_limit:
domain: public-api descriptors:
- key: api_key rate_limit:
unit: second requests_per_unit: 50 burst: 100
- key: api_key value: payments. write rate_limit:
unit: second requests_per_unit: 5 burst: 10

8. 2 NGINX (Lua + Redis, פסאודו)

nginx lua_shared_dict limits 10m;

location /api/ {
access_by_lua_block {
local key = ngx. var. arg_apikey.. ":".. ngx. var. request_method.. ":".. ngx. var. uri
-- token bucket in Redis (evalsha)
local allowed, retry_after = ratelimit_allow(key, 50, 100) -- r=50/s, b=100 if not allowed then ngx. header["Retry-After"] = retry_after return ngx. exit(429)
end
}
proxy_pass http://backend;
}

8. 3 גבולות תחרותיים (קוד פסאודו)

pseudo on_request_start(key):
if redis. incr_with_ttl("sem:" + key, ttl=60) > MAX_CONCURRENCY:
redis. decr("sem:" + key); reject(429)
on_request_finish(key):
redis. decr("sem:" + key)

8. 4 GCRA (פסאודוקודה)

pseudo params: r tokens/sec, burst b tat = redis. get(key) or now allowed_time = tat - (b / r)
if now < allowed_time: reject(429, retry_after = allowed_time - now)
tat_next = max(tat, now) + 1/r redis. set(key, tat_next, ttl = ceil(b/r) + safety)

9) אינטגרציה עם מגשים מחדש, פסקי זמן ומעגל חשמלי

תקצוב חוזר: להגביל את נתח המגשים מחדש ל-X% מהתנועה הראשית.
ג 'יטר: כאשר חוזרים אחורה, תמיד מוסיפים עצבנות - מפחית התפרצויות סינכרוניות.
מפסק מעגל: אם יש שגיאה גבוהה (”5xx”, timeouts), להוריד את הגבולות או להעביר חלק מהנתיבים ל ”קריאה בלבד”.
גידור: מסודר; קח בחשבון עלות כדי להימנע מהכפלת התקציב שלך.

10) יכולת תצפית וניהול

”rps _ lieved”, ”rps _ block”, ”429 _ rate”, ”retry _ after _ avg”, ”burst _ used”, ”cuta _ lever”, ”active _ concurrency”.
תוויות: על ידי הגבלת מפתח, אזור, סוף נקודה, תכנית.
רישומי החלטות (נדגמו): גורם לכשל, דלפקי זרם, מפתח TTL.
לוחות מחוונים: כרטיסי חום לפי מפתחות/נקודות סוף, לקוחות ”חמים”.
התראות: צמיחה של 429> 2-5% במסלולים קריטיים, ”תשישות” תכופה של מכסות, חוסר איזון של רסיסים.

11) בדיקה ואימות

בדיקות חוזה של מדיניות (אם-אז שולחנות).
טעינה: התפרצויות (x10 מ-r), נפח ארוך, תבניות ”מלוכלכות” (slow-POST, קשרים ארוכים).
תנועת כאוס: נחלים לא אחידים, סחף שעון, ירידה רדיס/רשת.
הכללה A/B: Canary rollout limits, shadow-solutions (רישום, אך לא לחסום) לפני הכללה.

12) מקרי קצה ודקויות

skew: השתמש 'עכשיו' () ממקור אחד (שרת), לא מכותרות לקוח.
Idempotency-Key: עבור כתיבה - מפחית הגברה ברטראס.
פעולות אצווה: להגביל את גודל המנה ואת העלות הכוללת.
סקר ארוך/שקע אינטרנט: להגביל את מספר הערוצים/מנויים ומשך זמן.
התחלה קרה: ”חם” התחלה של דלפקים/טעינה מראש; אחרת פרצים של 429 כוזבים.
בקשות יקרות מבחינה חישובית: הגבלה על ביצוע ההיגיון העסקי.
TTL: גבולות המפתחות יכסו את שולי החלון + בטיחות.

13) הסלמה באנטיבו

שלבים: אזהרה * 429 + ”Retry-After” # אתגר (Captcha/puzle) * בלוק זמני.
אותות: טביעת אצבע התקן, התנהגות סמן/תזמון, TOR/פרוקסי/אירוח.
המדיניות חייבת להיות דטרמיניסטית וניתנת לרבייה לזיהוי פלילי.

14) בטיחות וציות

מכחיש כברירת מחדל על מסלולים קריטיים (כתיבה/מימון).
ביקורת: לשמור על החלטות על גבולות לתיקים רגולטוריים וביקורות תקרית.
למפתחות מוגבלים אסור לחשוף מידע אישי ביומנים.

15) רשימת מוכנות למומחים

[ ] להגביל מפתחות ודגם עלות מוגדרים.

[ ] אלגוריתם נבחר (דלי סמלי/GCRA) ואחסון (Redis/Gateway).

[ מדיניות ] ללקוחות רובד + נתיכים גלובליים.

[ ] גבולות תחרותיים לעסקאות ארוכות טווח.

[ ] תקציב חוזר, חזרה עם ג 'יטר, אינטגרציה עם מפסק מעגל.

[ ] לוחות מחוונים/התראות, רישומי החלטות.

[ ] הקנריים במצב צל.

[ ] מבחני התפרצויות, פלאטיוס ארוך, כשלים רדיס, רפיון שעון.

[ תיעוד לקוח ]: 429, קודים ”Retry-After”, דוגמאות גיבוי מעריכיות.

16) TL; DR

השתמש בדלי אסימון או GCRA עם Redis/Gateway, הגבלת עיצוב מפתחות ועלויות בקשה, הוספת סמאפורות תחרותיות לפעולות ארוכות, אינטגרציה עם Restry-Backer, צג 429 ו-burst cability, גלגל מגבלות באמצעות canary/shadow ותבדוק פרצים וכשל אחסון