Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

הגדרת תורי משימות ב-Cloud Tasks

אפשר להגדיר את התור של Cloud Tasks כשיוצרים את התור או בכל שלב אחר. ההגדרה חלה על כל המשימות בתור הזה.

יש שלושה היבטים בסיסיים להגדרת התורים:

תכנון מסלול
מגבלות קצב
פרמטרים של ניסיון חוזר

הגדרה של ניתוב ברמת התור

הגדרת ניתוב ברמת התור מחליפה את הניתוב שנקבע ברמת המשימה. האפשרות הזו שימושית אם רוצים להשתמש ב-Cloud Tasks כמאגר זמני לפני שירות היעד, או אם צריך לשנות את הניתוב של כל המשימות בתור.

ניתוב ברמת התור חל על:

משימות שנמצאות בתור
משימות שנוספו לתור אחרי שהוגדר ניתוב ברמת התור

מגבלות

ניתוב ברמת התור לא תואם למפתחות הצפנה בניהול הלקוח (CMEK) של Cloud Key Management Service ‏ (Cloud KMS). אם CMEK מופעל, אי אפשר לבצע את הפעולות הבאות:

יצירת משימות בתור עם ניתוב ברמת התור
החלת ניתוב ברמת התור

הגדרת ניתוב ברמת התור למשימות HTTP

אפשר להגדיר תור שיעקוף את הניתוב ברמת המשימה כשיוצרים את התור או כשמעדכנים אותו. כדי להגדיר ניתוב ברמת התור, מגדירים את הפרמטר uriOverride של התור למסלול המועדף.

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

להשהות את התור מריצים את הפקודה הבאה:
```
  gcloud tasks queues pause QUEUE_ID
  
```
מחליפים את QUEUE_ID במזהה התור.
עדכון או הסרה של ניתוב ברמת התור.
- כדי לעדכן את הניתוב ברמת התור, מגדירים את הפרמטר uriOverride למסלול המעודכן.
- כדי להסיר ניתוב ברמת התור באמצעות API ל-REST או API ל-RPC:
  - ‫API בארכיטקטורת REST: שולחים בקשת patch לתור עם מטען ייעודי (payload) ריק והפרמטר updateMask מוגדר לערך httpTarget.
  - ‫RPC API: שולחים updateQueueRequest לתור עם מטען ייעודי ריק והפרמטר update_mask מוגדר לערך http_target.
בדוגמה הבאה נעשה שימוש ב-API בארכיטקטורת REST כדי לעדכן את המארח שאליו מנותבות המשימות:
```
curl -X PATCH -d @- -i \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  "https://cloudtasks.googleapis.com/v2/projects/PROJECT_ID/locations/LOCATION/queues/QUEUE_ID?updateMask=httpTarget.uriOverride" << EOF
{
  "httpTarget": {"uriOverride":{"host":"NEW_HOST"}}
}
EOF
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ACCESS_TOKEN: אסימון הגישה. אפשר לקבל את זה על ידי הרצת הפקודה הבאה במסוף:
```
gcloud auth application-default login
gcloud auth application-default print-access-token
```
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud . כדי לקבל את המידע הזה, מריצים את הפקודה הבאה בטרמינל:
```
gcloud config get-value project
```
- ‫LOCATION: המיקום של התור.
- ‫NEW_HOST: המארח החדש שאליו רוצים להפנות את התור.
מחכים דקה.

יכול להיות שיחלפו עד דקה עד שההגדרה החדשה תיכנס לתוקף. ההמתנה לפני חידוש התור עוזרת למנוע שליחה של משימות עם ההגדרה הישנה.
כדי להמשיך את התור, מריצים את הפקודה הבאה:
```
gcloud tasks queues resume QUEUE_ID
```

הגדרה של ניתוב ברמת התור למשימות App Engine

כדי להגדיר ניתוב ברמת התור למשימות של App Engine, מגדירים את הפרמטר appEngineRoutingOverride של התור לשירות ולגרסה המועדפים של App Engine.

הגדרה של ניתוב ברמת התור וביטול של ניתוב ברמת המשימה:
```
gcloud tasks queues update QUEUE_ID \
    --routing-override=service:SERVICE,version:VERSION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫QUEUE_ID: מזהה התור (השם הקצר שלו).
- ‫SERVICE: שירות העובדים של App Engine שאחראי לטיפול במשימות.
- ‫VERSION: גרסת האפליקציה.
לדוגמה, אם הגדרתם שירות עובדים לטיפול בכל המשימות בתור, תוכלו להפנות לשירות הזה ולגרסת ברירת המחדל:
```
gcloud tasks queues update QUEUE_ID \
    --routing-override=service:SERVICE
```

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

gcloud tasks queues describe QUEUE_ID --location=LOCATION

מחליפים את LOCATION במיקום של התור.

הפלט אמור להיראות כך:

appEngineRoutingOverride:
  host: SERVICE.PROJECT_ID.appspot.com
  service: SERVICE
name: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID
rateLimits:
  maxBurstSize: 100
  maxConcurrentDispatches: 1000
  maxDispatchesPerSecond: 500.0
retryConfig:
  maxAttempts: 100
  maxBackoff: 3600s
  maxDoublings: 16
  minBackoff: 0.100s
state: RUNNING

כדי להסיר ניתוב ברמת התור, מריצים את הפקודה הבאה:
```
gcloud tasks queues update QUEUE_ID \
    --clear-routing-override
```
כשמסירים ניתוב ברמת התור, הניתוב ברמת המשימה חל על משימות בתור ועל משימות שנוספו לתור בעתיד.

הגדרת הגבלת קצב של יצירת בקשות

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

כדי להגדיר את הקצב המקסימלי ואת מספר המשימות המקבילות שאפשר לשלוח מתור, מריצים את הפקודה הבאה:
```
gcloud tasks queues update QUEUE_ID \
    --max-dispatches-per-second=DISPATCH_RATE \
    --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫QUEUE_ID: מזהה התור (השם הקצר שלו).
- ‫DISPATCH_RATE: תעריף המשלוח. זהו שיעור הרענון של האסימונים בדלי. בתנאים שבהם יש זרימה יציבה יחסית של משימות, זה שווה לקצב שבו המשימות נשלחות.
- ‫MAX_CONCURRENT_DISPATCHES: המספר המקסימלי של משימות בתור שיכולות לפעול בו-זמנית.
לדוגמה, אם יצרתם תור בלי להגדיר פרמטרים, אתם יכולים לעדכן את המספר המקסימלי של משימות מקבילות באמצעות הפקודה הבאה:
```
gcloud tasks queues update QUEUE_ID \
    --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES
```

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

gcloud tasks queues describe QUEUE_ID --location=LOCATION

מחליפים את LOCATION במיקום של התור.

הפלט אמור להיראות כך:

name: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID
rateLimits:
  maxBurstSize: 100
  maxConcurrentDispatches: MAX_CONCURRENT_DISPATCHES
  maxDispatchesPerSecond: 500.0
retryConfig:
  maxAttempts: 100
  maxBackoff: 3600s
  maxDoublings: 16
  minBackoff: 0.100s
state: RUNNING

שיטות להגדרת קצב העיבוד של התור

אפשר להגדיר את קצב העיבוד של התור באמצעות Cloud Tasks API או באמצעות העלאה של קובץ queue.yaml. שתי השיטות יוצרות תורים שמתבססים על אותו מנגנון.

בשני המקרים, התור משתמש באלגוריתם token bucket כדי לשלוט בקצב הביצוע של המשימות. לכל תור שנקרא בשם יש מאגר שבו נשמרים האסימונים שלו.

בכל פעם שהאפליקציה מבצעת משימה, טוקן מוסר מהדלי. התור ממשיך לעבד משימות עד שמאגר האסימונים שלו מתרוקן. המערכת ממלאת מחדש את המאגר באסימונים חדשים באופן רציף על סמך קצב max_dispatches_per_second שאתם מציינים לתור. אם התור שלכם מכיל משימות לעיבוד, והקטגוריה של התור מכילה טוקנים, המערכת מעבדת בו-זמנית את כל המשימות שיש להן טוקנים, עד לערך max_concurrent_dispatches שהגדרתם.

עומס לא אחיד יכול לגרום למספר האסימונים בקטגוריה לגדול באופן משמעותי, מה שעלול להוביל לעיבוד מהיר של בקשות כשמגיעה כמות גדולה של בקשות. במקרה כזה, יכול להיות שקצב השליחה בפועל של התור יהיה גבוה מקצב max_dispatches_per_second, מה שיגרום לצריכת משאבי מערכת ולהתחרות עם בקשות להצגת מודעות למשתמשים. במקרים שבהם משתמשים בתורים כדי לנהל את שיעורי השליחה על סמך הסכמי רמת שירות (SLA) איטיים יחסית לשירותים במורד הזרם, זה עלול להוביל לשגיאות כמו HTTP 429 (יותר מדי בקשות) או HTTP 503 (השירות לא זמין).

כשמשתמשים ב-method כלשהי של Cloud Tasks API, יש שני שדות שבהם אפשר להגדיר את קצב השליחה של התור:
- max_dispatches_per_second
- max_concurrent_dispatches
השדה השלישי, max_burst_size, מחושב על ידי המערכת על סמך הערך שהגדרתם בשדה max_dispatches_per_second. מידע נוסף זמין במאמר בנושא הודעות RateLimits.
כשמשתמשים בqueue.yaml method, אפשר להגדיר את כל שלושת הרכיבים:
- ‫max_concurrent_requests, ששווה ל-max_concurrent_dispatches
- ‫rate, ששווה ל-max_dispatches_per_second
- ‫bucket_size, ששווה ל-max_burst_size

ברוב המקרים, שימוש בשיטת Cloud Tasks API והגדרת max_burst_size על ידי המערכת יוצרים קצב יעיל מאוד לניהול של פרצי בקשות. עם זאת, במקרים מסוימים, במיוחד כשנדרש קצב איטי יחסית, אפשר לקבל יותר שליטה באמצעות שימוש בשיטה queue.yaml כדי להגדיר ידנית את bucket_size לערך קטן, או באמצעות הגדרת max_concurrent_dispatches לערך קטן באמצעות Cloud Tasks API.

הגדרת פרמטרים של ניסיון חוזר

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

מריצים את הפקודה הבאה כדי לציין את המספר המקסימלי של פעמים לניסיון חוזר של משימות שנכשלו בתור, להגדיר מגבלת זמן לניסיונות חוזרים ולשלוט במרווח הזמן בין הניסיונות:
```
gcloud tasks queues update QUEUE_ID \
    --max-attempts=MAX_ATTEMPTS \
    --max-retry-duration=MAX_RETRY_DURATION \
    --min-backoff=MIN_INTERVAL \
    --max-backoff=MAX_INTERVAL \
    --max-doublings=MAX_DOUBLINGS
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫QUEUE_ID: מזהה התור (השם הקצר שלו).
- ‫MAX_ATTEMPTS: המספר המקסימלי של הניסיונות לביצוע משימה, כולל הניסיון הראשון. כדי לאפשר מספר בלתי מוגבל של ניסיונות חוזרים, צריך להגדיר את הדגל הזה ל--1. אם MAX_ATTEMPTS מוגדר לערך satisfied או לערך -1, המדיניות MAX_RETRY_DURATION עדיין חלה.
- ‫MAX_RETRY_DURATION: משך הזמן המקסימלי לניסיון חוזר של משימה שנכשלה, שנמדד מהניסיון הראשון לבצע את המשימה. הערך חייב להיות מחרוזת שמסתיימת ב-s, כמו 5s. כדי לציין משך זמן בלתי מוגבל, מגדירים את הדגל הזה לערך 0. אם התנאי MAX_RETRY_DURATION מתקיים או שהערך שלו הוא 0, המדיניות MAX_ATTEMPTS עדיין חלה.
הערה: אם הערך של MAX_ATTEMPTS שונה מ--1 והערך של MAX_RETRY_DURATION גדול מאפס, Cloud Tasks מפסיק את הניסיון החוזר כשהתנאים של MAX_ATTEMPTS ושל MAX_RETRY_DURATION מתקיימים, או כשהמשימה מבוצעת בהצלחה. אם המשימה תנסה MAX_ATTEMPTS פעמים והזמן MAX_RETRY_DURATION יעבור, לא יבוצעו ניסיונות נוספים והמשימה תימחק. אם הערך של MAX_ATTEMPTS הוא -1 והערך של MAX_RETRY_DURATION הוא 0, המערכת מנסה שוב לבצע את המשימה עד שמגיעים למגבלת משך השמירה המקסימלי של המשימה.
- ‫MIN_INTERVAL: משך הזמן המינימלי להמתנה בין ניסיונות חוזרים. הערך חייב להיות מחרוזת שמסתיימת ב-s, למשל 5s.
- ‫MAX_INTERVAL: משך הזמן המקסימלי להמתנה בין ניסיונות חוזרים. הערך חייב להיות מחרוזת שמסתיימת ב-s, למשל 5s.
- ‫MAX_DOUBLINGS: המספר המקסימלי של הפעמים שבהן המרווח בין ניסיונות חוזרים של משימה שנכשלה יוכפל לפני שההגדלה תהפוך לקבועה. מרווח הזמן בין ניסיונות חוזרים של משימה מתחיל ב-MIN_INTERVAL, מוכפל MAX_DOUBLINGS פעמים, ואז גדל באופן לינארי. לבסוף, המערכת מנסה שוב במרווחי זמן של MAX_INTERVAL עד MAX_ATTEMPTS פעמים.
  
  לדוגמה, אם MIN_INTERVAL הוא 10s,‏ MAX_INTERVAL הוא 300s ו-MAX_DOUBLINGS הוא 3, מרווח הניסיון החוזר יוכפל 3 פעמים, יגדל באופן לינארי ב-‎2^3 * 10s, ואז יתבצע ניסיון חוזר במרווחים של MAX_INTERVAL עד שהמשימה תנסה MAX_ATTEMPTS פעמים: 10 שניות, 20 שניות, 40 שניות, 80 שניות, 160 שניות, 240 שניות, 300 שניות, 300 שניות וכן הלאה.
פרטים נוספים על הפרמטרים זמינים בהגדרות של RetryConfig עבור המשאב Queue.
כדי לוודא שהתור הוגדר בהצלחה, מריצים את הפקודה הבאה:
```
gcloud tasks queues describe QUEUE_ID --location=LOCATION
```
מחליפים את LOCATION במיקום של התור.

הפלט צריך לכלול את פרמטרי הניסיון החוזר שהגדרתם.

המאמרים הבאים

מידע נוסף על יצירת משימות של HTTP Target
מידע על יצירת משימות ב-App Engine
מידע נוסף על ניהול תורים זמין בהפניית API של RPC.
מידע נוסף על ניהול תורים מופיע בהפניית API בארכיטקטורת REST.