מאפייני המינוי

בדף הזה מתוארים המאפיינים שמשותפים לכל סוגי המינויים ל-Pub/Sub. אפשר להגדיר את המאפיינים האלה כשיוצרים או מעדכנים מינוי.

משך השמירה של ההודעות

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

אלה הערכים של האפשרות משך שמירת ההודעות:

  • ערך ברירת המחדל = 7 ימים
  • ערך מינימלי = 10 דקות
  • הערך המקסימלי הוא 31 ימים

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

  • מינויים לא פעילים. מחיקת מינויים לא פעילים כדי להימנע מחיובים על שמירת הודעות במינוי.

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

  • עיכובים בעיבוד. כדאי להוסיף עוד מנויים (אם אפשר) כדי לעבד את ההודעות תוך יום.

שמירת הודעות שאושרו

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

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

תקופת התפוגה

האפשרות תקופת התפוגה מאפשרת להאריך את תקופת התפוגה של המינוי.

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

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

אלה הערכים של האפשרות תקופת התפוגה:

  • ערך ברירת המחדל = 31 ימים
  • ערך מינימלי = יום אחד

כדי למנוע את סיום המינוי, מגדירים את תקופת התפוגה ל-never expire.

המועד האחרון לאישור

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

הערכים האפשריים לאפשרות מועד אחרון לאישור:

  • ערך ברירת המחדל = 10 שניות
  • הערך המינימלי הוא 10 שניות
  • הערך המקסימלי הוא 600 שניות

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

טרנספורמציות של הודעות בודדות (SMT)

מערכות SMT מאפשרות לבצע שינויים קלים במאפיינים ובנתונים של הודעות ישירות ב-Pub/Sub. התכונה הזו מאפשרת טיוב נתונים, סינון, או המרת פורמטים לפני שההודעות מועברות ללקוח מנוי.

מידע נוסף זמין במאמרים סקירה כללית על SMTs ויצירת מינוי עם SMTs.

מסנן מינויים

משתמשים באפשרות Subscription filter כדי לציין מחרוזת עם ביטוי סינון. אם יש מסנן למינוי, המינוי מספק רק את ההודעות שתואמות למסנן. שירות Pub/Sub מאשר באופן אוטומטי את ההודעות שלא תואמות למסנן.

  • אפשר לסנן הודעות לפי המאפיינים שלהן, אבל לא לפי הנתונים שבהודעה.

  • אם לא מציינים, המינוי לא מסנן הודעות והמנויים מקבלים את כל ההודעות.

  • אי אפשר לשנות או להסיר מסננים אחרי שמחילים אותם.

כשמקבלים הודעות ממינוי עם מסנן, לא חלים דמי יציאה על ההודעות שהמערכת של Pub/Sub מאשרת באופן אוטומטי. תחויבו בדמי מסירת הודעות ובדמי אחסון שקשורים לחיפוש עבור ההודעות האלה.

מידע נוסף מופיע במאמר סינון הודעות ממינוי.

סדר ההודעות

כברירת מחדל, יכול להיות שההודעות ב-Pub/Sub לא יימסרו לפי הסדר שבו הן פורסמו. אם מפעילים את האפשרות Message ordering (סידור הודעות) במינוי, כל ההודעות שנשלחות באותו אזור, עם אותו ordering key (מפתח סידור), מתקבלות לפי הסדר שבו הן פורסמו.

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

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

נושא להודעות ללא מוצא

אם אי אפשר למסור הודעה אחרי מספר מוגדר של ניסיונות מסירה, או אם אפליקציה רשומה לא יכולה לאשר את קבלת ההודעה, מערכת Pub/Sub יכולה לפרסם מחדש את ההודעה בנושא להודעות ללא מוצא שהוגדר מראש.

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

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

מידע נוסף זמין במאמר בנושא נושאים של הודעות שלא נמסרו.

מדיניות ניסיון חוזר

אם חלף המועד האחרון לאישור או אם נרשם מנוי שמגיב באישור שלילי, מערכת Pub/Sub יכולה לשלוח את ההודעה שוב. ניסיון המסירה החוזר הזה נקרא מדיניות הניסיון החוזר של המינוי.

כברירת מחדל, מדיניות הניסיון החוזר של מינוי מוגדרת לשימוש באפשרות ניסיון חוזר מיידי. באפשרות הזו, Pub/Sub שולח מחדש את ההודעה כשתאריך היעד לאישור מסתיים או כשמנוי מגיב באישור שלילי.

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

הנה כמה הנחיות להגדרת הערכים של ההשהיה לפני ניסיון חוזר (backoff) המקסימלית והמינימלית:

  • אם מגדירים את הערך המקסימלי של משך ההשהיה, ערך ברירת המחדל של משך ההשהיה המינימלי הוא 10 שניות.

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

  • משך ההשהיה לפני ניסיון חוזר (backoff) הארוך ביותר שאפשר לציין הוא 600 שניות.

מדיניות ניסיון חוזר והודעות בחבילות

אם ההודעות נמצאות באצווה, Pub/Sub מתחיל את הנסיגה האקספוננציאלית כשמתרחש אחד מהמקרים הבאים:

  • המנוי שולח אישור שלילי לכל הודעה בחבילה.

  • המועד האחרון לאישור חלף.

מדיניות ניסיון חוזר ומינוי לדחיפה

אם אתם מקבלים הודעות ממינוי דחיפה, יכול להיות שמערכת Pub/Sub תשלח מחדש הודעות אחרי השהיית השליחה במקום אחרי משך ההשהיה המעריכית לפני ניסיון חוזר. כשהשהיית השליחה ארוכה יותר ממשך ההשהיה המעריכית לפני ניסיון חוזר, מערכת Pub/Sub שולחת מחדש הודעות שלא אושרו אחרי השהיית השליחה.

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