שיטות מומלצות להרשמה לנושא ב-Pub/Sub

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

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

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

בחירת המינוי המתאים

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

מומלץ להשתמש במינויי דחיפה בתרחישים הבאים:

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

  • לקוח המנוי לא יכול לשלוח בקשות יוצאות.

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

במקרים כלליים, מומלץ להשתמש בספריית הלקוח ברמה גבוהה. אם אתם משתמשים במשיכה אונארית, אל תגדירו את returnImmediately ל-true. הגדרה של true משפיעה לרעה על ביצועי המשיכה. השדה returnImmediately הוצא משימוש.

עיבוד הודעות לפני אישור קבלתן

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

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

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

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

הגדרת בקרת זרימה של מנויים לעליות חדות זמניות בתנועה

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

כדי להגדיר בקרת זרימה, צריך להגדיר ערכים מתאימים ל-maximum outstanding messages ול-total outstanding message bytes. ערכי ברירת המחדל של המשתנים האלה לבקרת זרימה ושמות המשתנים עשויים להיות שונים בספריות לקוח שונות.

  • Maximum outstanding messages: המספר המקסימלי של הודעות שנשלחו ללקוח, וש-Pub/Sub לא קיבל עליהן אישור או אישור שלילי.

  • Total outstanding message bytes מגדיר את הגודל הכולל המקסימלי של הודעות שנמסרו ללקוח, וש-Pub/Sub לא קיבל עליהן אישור או אישור שלילי.

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

טיפול במשלוחים כפולים

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

שליחה חוזרת עקבית של הרבה הודעות

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

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

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

העברה חוזרת של הודעות מדי פעם

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

שליחה חוזרת של כמה הודעות שוב ושוב

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

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

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

שיטות מומלצות להעברת הודעות לפי סדר בהרשמה

אם אתם משתמשים בסדר ההודעות, ודאו את הדברים הבאים:

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

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

  • אישור הודעות לפי הסדר. כשמשתמשים במסירה לפי סדר, אישורי קבלה של הודעות מאוחרות יותר לא מעובדים עד שאישורי הקבלה של הודעות מוקדמות יותר מעובדים לפי מפתח סדר. לדוגמה, אם יש לכם את ההודעות 1, 2 ו-3 עם אותו מפתח סדר, ואתם מקבלים את כולן ומאשרים רק את הודעה 3, השירות לא יחשיב את הודעה 3 כמאושרת עד שתאשרו גם את הודעות 1 ו-2. אם האישורים על הודעות 1 ו-2 לא מתקבלים, הודעות 1, 2 ו-3 נשלחות מחדש.

סיכום של השיטות המומלצות

בטבלה הבאה מפורטות השיטות המומלצות שמופיעות במאמר הזה:

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

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