במסמך הזה מפורטת סקירה כללית של מינוי מסוג 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 לנקודת קצה תקינה. כדי להפסיק את השליחה באופן סופי, מוחקים את המינוי.
השהיית ניסיון חוזר
אם מנוי ל-push שולח יותר מדי אישורים שליליים, יכול להיות ש-Pub/Sub יתחיל להעביר הודעות באמצעות השהיית push. כש-Pub/Sub משתמש בהשהיה לפני ניסיון חוזר (backoff) של דחיפת הודעות, הוא מפסיק לשלוח הודעות למשך פרק זמן שנקבע מראש. טווח הזמן הזה יכול להיות בין 100 אלפיות שנייה ל-60 שניות. אחרי שהזמן חולף, Pub/Sub מתחיל לספק הודעות שוב.
השהיה מעריכית לפני ניסיון חוזר (exponential backoff) של הודעות Push משתמשת באלגוריתם השהיה מעריכית לפני ניסיון חוזר כדי לקבוע את העיכוב ש-Pub/Sub משתמש בו בין שליחת ההודעות. משך הזמן הזה מחושב על סמך מספר אישורי השלילה שמנויים ב-Push שולחים.
לדוגמה, אם מנוי מסוג Push מקבל חמש הודעות בשנייה ושולח אישור שלילי אחד בשנייה, מערכת Pub/Sub מספקת הודעות כל 500 מילישניות בערך. לחלופין, אם מנוי ה-push שולח חמישה אישורי קבלה שליליים בכל שנייה, Pub/Sub מעביר הודעות כל 30 עד 60 שניות.
חשוב לזכור את הנקודות הבאות לגבי השהיה של שליחת נתונים:
- אי אפשר להפעיל או להשבית את ההשהיה לפני ניסיון חוזר (backoff). אי אפשר גם לשנות את הערכים שמשמשים לחישוב העיכוב.
- הפעלת טריגרים של השהיה חוזרת בפעולות הבאות:
- כשמתקבל אישור שלילי.
- כשתוקף האישור של הודעה פג.
- ההשהיה של שליחת הודעות חלה על כל ההודעות במינוי (גלובלי).
שיעור מסירה
מערכת Pub/Sub מתאימה את מספר בקשות הדחיפה המקבילות באמצעות אלגוריתם של התחלה איטית. המספר המקסימלי המותר של בקשות push בו-זמניות הוא חלון ה-push. חלון השליחה מתרחב בכל מסירה מוצלחת ומצטמצם בכל מסירה שנכשלה. המערכת מתחילה עם חלון קטן של ספרה אחת.
כשהמנוי מאשר את ההודעות, החלון גדל באופן אקספוננציאלי. במינויים שבהם המנויים מאשרים יותר מ-99% מההודעות וזמן האחזור הממוצע של בקשות הדחיפה הוא פחות משנייה אחת, חלון הדחיפה צריך להתרחב מספיק כדי לעמוד בקצב של כל נפח העברת נתונים של פרסום.
השיהוי של בקשת הדחיפה כולל את השלבים הבאים:
זמן האחזור הלוך ושוב ברשת בין שרתי Pub/Sub לבין נקודת הקצה של הדחיפה
זמן העיבוד של המנוי
אחרי 3,000 הודעות שלא נשלחו בכל אזור, החלון גדל באופן לינארי כדי למנוע מקצה ה-Push לקבל יותר מדי הודעות. אם זמן האחזור הממוצע עולה על שנייה אחת או אם המנוי מאשר פחות מ-99% מהבקשות, החלון מצטמצם לגבול התחתון של 3,000 הודעות בהמתנה.
מידע נוסף על המדדים שבהם אפשר להשתמש כדי לעקוב אחרי מסירת הודעות Push זמין במאמר מעקב אחרי מינויים ל-Push.
מכסות ומגבלות
מינויים להודעות פוש כפופים לסט של מכסות ומגבלות על משאבים.
המאמרים הבאים
יוצרים מינוי לנושא.
פתרון בעיות שקשורות למינוי דחיפה
יוצרים או משנים מינוי באמצעות ה-CLI של gcloud.
יוצרים או משנים מינוי באמצעות ממשקי API ל-REST.
יצירה או שינוי של מינוי באמצעות ממשקי API ל-RPC.