במסמך הזה מפורטת סקירה כללית של מינוי מסוג Push, תהליך העבודה שלו והמאפיינים שקשורים אליו.
במסירה בדחיפה, Pub/Sub יוזם בקשות לאפליקציית המנוי כדי למסור הודעות. ההודעות נשלחות לשרת או ל-webhook עם כתובת שאפשר לפנות אליהם באופן ציבורי, כמו בקשת HTTPS POST.
מינויים מסוג Push מצמצמים את התלות בספריות לקוח ובמנגנוני אימות ספציפיים ל-Pub/Sub. הן מתאימות גם לטכנולוגיות של שירותים בלי שרת (serverless) ועם שינוי גודל אוטומטי, כמו פונקציות Cloud Run, Cloud Run ו-Google Kubernetes Engine.
לפני שמתחילים
לפני שקוראים את המסמך הזה, חשוב לוודא שמכירים את הנושאים הבאים:
איך פועל Pub/Sub ומהם המונחים השונים שקשורים ל-Pub/Sub.
סוגי המינויים השונים ש-Pub/Sub תומך בהם, והסיבות לשימוש במינוי מסוג push.
תהליך העבודה של מינוי דחיפה
במינוי בדחיפה, שרת Pub/Sub יוזם בקשה ללקוח המנוי כדי להעביר הודעות.
בתמונה הבאה מוצג תהליך העבודה בין לקוח של מנוי לבין מנוי לשליחת הודעות פוש.
הנה תיאור קצר של תהליך העבודה שמופיע באיור 3:
- שרת Pub/Sub שולח כל הודעה כבקשת HTTPS ללקוח של המנוי בנקודת קצה שהוגדרה מראש. הבקשה הזו מוצגת כ-
PushRequestבתמונה. - נקודת הקצה מאשרת את קבלת ההודעה על ידי החזרת קוד סטטוס HTTP שמציין הצלחה. תשובה שלא מציינת הצלחה מעידה על כך ש-Pub/Sub צריך לשלוח מחדש את ההודעות. התשובה הזו מוצגת כ
PushResponseבתמונה. - Pub/Sub משנה באופן דינמי את קצב בקשות ה-push על סמך הקצב שבו הוא מקבל תגובות הצלחה.
מאפיינים של מינוי דחיפה
המאפיינים שאתם מגדירים למינוי לקבלת עדכונים בדחיפה קובעים איך לכתוב הודעות למינוי. מידע נוסף זמין במאמר בנושא מאפייני מינוי.
איך נקודות קצה של התראות פוש מקבלות הודעות
כש-Pub/Sub מעביר הודעה לנקודת קצה של push, אפשר לבחור אם לשלוח אותה עטופה או לא עטופה. כברירת מחדל, ההודעות נשלחות עטופות.
- עטוף. Pub/Sub שולח את ההודעה בתוכן ה-JSON של בקשת
POST. - Unwrapped Pub/Sub שולח את נתוני ההודעה הגולמיים ישירות כגוף ה-HTTP.
בדוגמאות הבאות מוצג גוף עטוף של בקשת JSON POST לנקודת קצה של הודעת פוש שמכילה את המחרוזת Hello there בשדה message.data
התוכן של בקשת POST הוא אובייקט JSON. נתוני ההודעה נמצאים בשדה message.data והם בקידוד Base64.
דוגמה לבקשה עם הערכים המינימליים
{ "message": { "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==", "messageId": "2070443601311540", "message_id": "2070443601311540", "publishTime": "2021-02-26T19:13:55.749Z", "publish_time": "2021-02-26T19:13:55.749Z" }, "subscription": "projects/myproject/subscriptions/mysubscription" }
דוגמה לבקשה עם הערכים המקסימליים
שימו לב שבדוגמה הזו מוצגים הערכים המקסימליים הנוכחיים, שיכולים להשתנות לאורך זמן. בנוסף, מיפוי המאפיינים יכול להכיל מגוון ערכים.
{ "deliveryAttempt": 5, "message": { "attributes": { "key": "value" }, "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==", "messageId": "2070443601311540", "message_id": "2070443601311540", "orderingKey": "key", "publishTime": "2021-02-26T19:13:55.749Z", "publish_time": "2021-02-26T19:13:55.749Z" }, "subscription": "projects/myproject/subscriptions/mysubscription" }
כדי לקבל הודעות ממינויים מסוג Push, צריך להשתמש ב-webhook ולעבד את הבקשות POST ש-Pub/Sub שולח לנקודת הקצה של ה-Push. מידע נוסף על עיבוד בקשות POST ב-App Engine זמין במאמר כתיבה של הודעות Pub/Sub ומענה להן.
אחרי שמקבלים בקשת Push, מחזירים קוד סטטוס של HTTP. כדי לאשר את קבלת ההודעה, מחזירים את אחד מקודי הסטטוס הבאים:
102200201202204
כדי לשלוח אישור שלילי להודעה, מחזירים קוד סטטוס אחר. אם שולחים אישור שלילי או שהמועד האחרון לאישור חלף, Pub/Sub שולח מחדש את ההודעה. אי אפשר לשנות את מועד האישור של הודעות ספציפיות שמתקבלות ממנויי Push.
אימות למינויי Push
אם מינוי דחיפה משתמש באימות, שירות Pub/Sub חותם על JWT ושולח את ה-JWT בכותרת ההרשאה של בקשת הדחיפה.
מידע נוסף על הגדרת אימות זמין במאמר אימות בקשות Push.
הפסקה והמשך של מסירת הודעות
כדי להפסיק באופן זמני את השליחה של בקשות מ-Pub/Sub לנקודת הקצה של הדחיפה, משנים את המינוי למשיכה. יכול להיות שיחלפו כמה דקות עד שהשינוי ייכנס לתוקף.
כדי להמשיך בשליחת הודעות פוש, צריך להגדיר שוב את כתובת ה-URL לנקודת קצה תקינה. כדי להפסיק את השליחה באופן סופי, מוחקים את המינוי.
השהיית ניסיון חוזר
אם מנוי להודעות פוש שולח יותר מדי אישורים שליליים, יכול להיות ש-Pub/Sub יתחיל להעביר הודעות באמצעות השהיית פוש. כש-Pub/Sub משתמש בהשהיה לפני ניסיון חוזר (backoff) של דחיפת הודעות, הוא מפסיק לשלוח הודעות למשך פרק זמן שנקבע מראש. טווח הזמן הזה יכול להיות בין 100 אלפיות שנייה ל-60 שניות. אחרי שהזמן חולף, Pub/Sub מתחיל לספק הודעות שוב.
השהיה מעריכית לפני ניסיון חוזר (exponential backoff) של הודעות בדחיפה משתמשת באלגוריתם של השהיה מעריכית לפני ניסיון חוזר כדי לקבוע את העיכוב שבו Pub/Sub משתמש בין שליחת ההודעות. משך הזמן הזה מחושב על סמך מספר אישורי השלילה שמנויים ב-Push שולחים.
לדוגמה, אם מנוי מסוג Push מקבל חמש הודעות בשנייה ושולח אישור שלילי אחד בשנייה, מערכת Pub/Sub תעביר הודעות כל 500 מילישניות בערך. לחלופין, אם מנוי ה-push שולח חמישה אישורי קבלה שליליים בכל שנייה, Pub/Sub מעביר הודעות כל 30 עד 60 שניות.
חשוב לזכור את הנקודות הבאות לגבי השהיה של שליחת נתונים:
- אי אפשר להפעיל או להשבית את ההשהיה לפני ניסיון חוזר (backoff). אי אפשר גם לשנות את הערכים שמשמשים לחישוב העיכוב.
- הפעלת טריגרים של השהיה חוזרת בפעולות הבאות:
- כשמתקבל אישור שלילי.
- כשתוקף האישור של הודעה פג.
- ההשהיה של שליחת הודעות חלה על כל ההודעות במינוי (גלובלי).
שיעור מסירה
מערכת Pub/Sub מתאימה את מספר בקשות הדחיפה המקבילות באמצעות אלגוריתם של התחלה איטית. המספר המקסימלי המותר של בקשות push בו-זמניות הוא חלון ה-push. חלון השליחה מתרחב בכל מסירה מוצלחת ומצטמצם בכל מסירה שנכשלה. המערכת מתחילה עם גודל חלון קטן של ספרה אחת.
כשהמנוי מאשר את ההודעות, החלון גדל באופן אקספוננציאלי. במינויים שבהם המנויים מאשרים יותר מ-99% מההודעות וזמן האחזור הממוצע של בקשות ה-Push הוא פחות משנייה אחת, חלון ה-Push צריך להתרחב מספיק כדי לעמוד בקצב של כל נפח העברת נתונים של פרסום.
השיהוי של בקשת הדחיפה כולל את השלבים הבאים:
זמן האחזור הלוך ושוב ברשת בין שרתי Pub/Sub לבין נקודת הקצה של הדחיפה
זמן העיבוד של המנוי
אחרי 3,000 הודעות שלא נשלחו בכל אזור, החלון גדל באופן לינארי כדי למנוע מקצה ה-Push לקבל יותר מדי הודעות. אם זמן האחזור הממוצע עולה על שנייה אחת או אם המנוי מאשר פחות מ-99% מהבקשות, החלון מצטמצם לגבול התחתון של 3,000 הודעות בהמתנה.
מידע נוסף על המדדים שבהם אפשר להשתמש כדי לעקוב אחרי מסירת הודעות Push זמין במאמר מעקב אחרי מינויים ל-Push.
מכסות ומגבלות
מינויים להודעות פוש כפופים לסט של מכסות ומגבלות על משאבים.
המאמרים הבאים
יוצרים מינוי לנושא.
פתרון בעיות שקשורות למינוי דחיפה
יוצרים או משנים מינוי באמצעות ה-CLI של gcloud.
יצירה או שינוי של מינוי באמצעות ממשקי API ל-REST.
יצירה או שינוי של מינוי באמצעות ממשקי API ל-RPC.