ב-Google Ads API, יש הגבלת קצב לפי שאילתות לשנייה (QPS) גם במזהי לקוחות וגם בפרויקטים ב-Google Cloud, באופן נפרד. ב-Google Ads API נעשה שימוש באלגוריתם token bucket כדי למדוד את הבקשות ולקבוע מגבלת QPS מתאימה, ולכן המגבלה המדויקת משתנה בהתאם לעומס השרת הכולל בכל זמן נתון.
המטרה של הגבלת קצב הבקשות היא למנוע ממשתמש אחד לשבש את השירות למשתמשים אחרים על ידי הצפת השרתים של Google Ads API במספר גדול של בקשות (בכוונה או שלא בכוונה).
בקשות שמפרות את המגבלות על קצב יצירת הבקשות יידחו עם השגיאה:
RESOURCE_TEMPORARILY_EXHAUSTED.
כדי להשתלט על האפליקציה ולצמצם את המגבלות על קצב הבקשות, אפשר לצמצם באופן פעיל את מספר הבקשות ולבצע ויסות של QPS בצד הלקוח.
יש כמה דרכים לצמצם את הסיכוי לחריגה ממגבלת הקצב. היכרות עם מושגים של דפוסי שילוב ארגוניים (EIP), כמו העברת הודעות, מסירה חוזרת והגבלת קצב הבקשות, יכולה לעזור לכם ליצור אפליקציית לקוח חזקה יותר.
השיטות המומלצות הבאות מסודרות לפי רמת המורכבות, מהפשוטות ביותר למעלה ועד לארכיטקטורות מורכבות יותר בהמשך:
הגבלת מספר המשימות בו-זמנית
אחת הסיבות לחריגה מהגבלות הקצב היא שאפליקציית הלקוח יוצרת מספר מוגזם של משימות מקבילות. אנחנו לא מגבילים את מספר הבקשות המקבילות שאפליקציית לקוח יכולה לשלוח, אבל המספר הזה יכול לחרוג מהמגבלה של בקשות לשנייה ברמת הפרויקט ב-Google Cloud.
מומלץ להגדיר גבול עליון סביר למספר הכולל של משימות מקבילות שיבצעו בקשות (בכל התהליכים והמכונות), ולבצע התאמות כדי לשפר את קצב העברת הנתונים בלי לחרוג ממגבלת הקצב.
בנוסף, אפשר לשקול הגבלת QPS בצד הלקוח (כדאי לעיין במאמר בנושא הגבלת קצב העברת נתונים ומגבילי קצב).
קיבוץ בקשות באצווה
כדאי לשקול לשלוח כמה פעולות בבקשה אחת. הדבר רלוונטי בעיקר לקריאות ל-Mutate עבור שירותים שונים. לדוגמה, אם אתם מעדכנים את הסטטוס של כמה מופעים של AdGroupAd, אתם יכולים לקרוא ל-MutateAdGroupAds פעם אחת ולהעביר כמה ערכים של operations במקום לקרוא ל-MutateAdGroupAds פעם אחת לכל AdGroupAd. במדריך שלנו בנושא פעולות בחבילות יש דוגמאות נוספות.
קיבוץ בקשות באצווה מצמצם את המספר הכולל של הבקשות ומפחית את הסיכון לחריגה ממגבלות הקצב של בקשות לדקה, אבל הוא עלול לגרום לחריגה ממגבלת הקצב של פעולות לדקה אם מבצעים מספר גדול של פעולות בחשבון יחיד.
ויסות נתונים והגבלת קצב
בנוסף להגבלת המספר הכולל של השרשורים באפליקציה, אפשר גם להטמיע מגבילי קצב בצד הלקוח. כך אפשר לוודא שכל השרשורים בתהליכים או באשכולות כפופים למגבלת QPS ספציפית בצד הלקוח.
אתם יכולים לעיין ב-Guava Rate Limiter או להטמיע אלגוריתם משלכם שמבוסס על token bucket בסביבה מקובצת. לדוגמה, אפשר ליצור טוקנים ולאחסן אותם באחסון טרנזקציוני משותף, כמו מסד נתונים, וכל לקוח יצטרך לקבל טוקן ולהשתמש בו לפני שהוא מעבד את הבקשה. אם נעשה שימוש בכל הטוקנים, הלקוח יצטרך לחכות עד ליצירת קבוצת הטוקנים הבאה.
הוספה לתור
תור הודעות הוא הפתרון לחלוקת עומס הפעולות, וגם לשליטה בשיעורי הבקשות והצרכנים. יש מספר אפשרויות של תורי הודעות – חלקן בקוד פתוח וחלקן קנייניות – ורבות מהן יכולות לפעול בשפות שונות.
כשמשתמשים בתורי הודעות, יכולים להיות כמה גורמים ששולחים הודעות לתור וכמה גורמים שמעבדים את ההודעות האלה. אפשר להטמיע מנגנוני ויסות בצד הצרכן על ידי הגבלת מספר הצרכנים בו-זמנית, או להטמיע מגבילי קצב או מנגנוני ויסות עבור היצרנים או הצרכנים.
לדוגמה, אם צרכן הודעות נתקל בשגיאה של חריגה ממגבלת קצב, הוא יכול להחזיר את הבקשה לתור כדי לנסות שוב. במקביל, הצרכן יכול גם להודיע לכל הצרכנים האחרים להשהות את העיבוד למשך כמה שניות כדי להתאושש מהשגיאה.