כדי לקבל הודעות שפורסמו בנושא מסוים, צריך ליצור מינוי לנושא הזה. רק הודעות שפורסמו בנושא אחרי יצירת המינוי זמינות ללקוחות רשומים. הלקוח הרשום מקבל ומעבד את ההודעות שפורסמו בנושא. נושא יכול לכלול כמה מינויים, אבל כל מינוי שייך לנושא אחד בלבד.
התכונה topic retention מאפשרת למנוי שמצורף לנושא לחזור אחורה בזמן ולהפעיל מחדש הודעות שפורסמו בעבר. מידע נוסף על התכונה זמין בנושא הפעלה מחדש ומחיקה של הודעות.
תהליך העבודה עם מינויים
אחרי שהודעה נשלחת למנוי, המנוי צריך לאשר את קבלת ההודעה.
אם הודעה נשלחת למסירה ומנוי עדיין לא אישר אותה, ההודעה נקראת 'הודעה בהמתנה'.
ב-Pub/Sub יש ניסיון חוזר לשלוח כל הודעה שלא אושרה עדיין. עם זאת, מערכת Pub/Sub מנסה לא למסור הודעה שלא נמסרה לאף אפליקציה רשומה אחרת באותו מינוי.
למנוי יש פרק זמן מוגבל שניתן להגדרה, שנקרא
ackDeadline, כדי לאשר את קבלת ההודעה שלא נמסרה. אחרי שהמועד האחרון חולף, ההודעה כבר לא נחשבת כהודעה שלא נמסרה, ומערכת Pub/Sub מנסה לשלוח אותה מחדש.
סוגי מינויים
כשיוצרים מינוי, צריך לציין את סוג מסירת ההודעות. Pub/Sub מציע את סוגי המינויים הבאים:
מינויים מסוג pull משתמשים בלקוח של נמען כדי לבקש הודעות משרת Pub/Sub.
מינויים מסוג Push משתמשים בשרת Pub/Sub כדי ליזום בקשות לאפליקציית המנוי לצורך העברת הודעות.
ייצוא מינויים ייצוא ההודעות ישירות למשאב Cloud de Confiance by S3NS. המינויים האלה כוללים:
מינויים ל-BigQuery מייצאים נתונים לטבלה ב-BigQuery.
מינויים ל-Bigtable (גרסת Preview) ייצוא נתונים לטבלת Bigtable.
מינויים ל-Cloud Storage מייצאים נתונים לקטגוריה של Cloud Storage.
כדי לבחור את המינוי המתאים לדרישות העסק, אפשר לעיין במאמר בנושא בחירת סוג מינוי. אפשר לעדכן את סוג המסירה של ההודעה למינוי בכל שלב אחרי שהוא נוצר.
מאפייני ברירת מחדל של מינוי
כברירת מחדל, ב-Pub/Sub יש אפשרות של לפחות מסירה אחת ללא הבטחות לגבי סדר המסירה בכל סוגי המינויים. לחלופין, אם להודעות יש מפתח סידור זהה והן נמצאות באותו אזור, אפשר להפעיל סידור הודעות. אחרי שמגדירים את המאפיין של סדר ההודעות, שירות Pub/Sub מעביר את ההודעות עם אותו מפתח סדר, ובסדר שבו שירות Pub/Sub מקבל את ההודעות.
ב-Pub/Sub יש גם תמיכה במסירה מדויקת של פעם אחת.
באופן כללי, Pub/Sub מעביר כל הודעה פעם אחת ובסדר שבו היא פורסמה. עם זאת, יכול להיות שההודעות יימסרו לא לפי הסדר או יותר מפעם אחת. יכול להיות ש-Pub/Sub ישלח מחדש הודעה גם אחרי שבקשת אישור להודעה תחזור בהצלחה. המסירה מחדש יכולה להיגרם מבעיות כמו הפעלה מחדש בצד השרת או בעיות בצד הלקוח. לכן, למרות שזה נדיר, אפשר לשלוח מחדש כל הודעה בכל שלב.
כדי לאפשר מסירה של הודעה יותר מפעם אחת, המנוי צריך להיות אידמפוטנטי כשמעבדים הודעות.
תפוגת המינוי
כברירת מחדל, תוקף המינויים יפוג אחרי 31 ימים של חוסר פעילות של המנוי או אם לא בוצעו עדכונים במינוי. דוגמאות לפעילויות של מנויים: חיבורים פתוחים, שליפות פעילות או דחיפות מוצלחות. אם Pub/Sub מזהה פעילות של מנוי או עדכון של מאפייני המינוי, השעון של מחיקת המינוי מתחיל מחדש. באמצעות מדיניות תפוגת מינוי, אתם יכולים להגדיר את משך חוסר הפעילות או להגדיר את המינוי כקבוע ללא קשר לפעילות. אפשר גם למחוק מינוי באופן ידני.
אפשר ליצור מינוי חדש עם אותו שם של מינוי שנמחק, אבל אין קשר בין המינוי החדש למינוי הישן. גם אם במינוי שנמחק היו הרבה הודעות שלא אושרו, במינוי חדש שייווצר עם אותו שם לא יהיו הודעות בהמתנה (הודעות שממתינות למסירה) בזמן היצירה.
המאמרים הבאים
בוחרים את סוג המינוי הנכון בהתאם לדרישות העסק.
הסבר על תהליך העבודה לכל סוג מינוי: