במסמך הזה אנחנו יוצאים מנקודת הנחה שאתם כבר מכירים את תהליך ההרשמה לנושא ב-Pub/Sub וקבלת הודעות בלקוח שלכם כמנויים.
אם אתם חדשים ב-Pub/Sub, כדאי לעיין באחד מהמדריכים למתחילים כדי ללמוד איך להריץ את Pub/Sub באמצעות המסוף, Google Cloud CLI או ספריות הלקוח.
בחירת המינוי המתאים
Pub/Sub מציע מינויים רגילים כמו מינויי push וpull. בנוסף למינויים הרגילים, Pub/Sub מציע גם מינויים לייצוא שמאפשרים לכם לאחסן הודעות ישירות במשאבGoogle Cloud , בלי ש-Dataflow ישמש כמתווך. לדוגמה, מינויים ל-BigQuery מאחסנים הודעות בטבלה ב-BigQuery.
מומלץ להשתמש במינויים לשליחת הודעות פוש בתרחישים הבאים:
אסור לכלול בקשת המינוי קוד שמייבא את ספריית הלקוח כתלות.
לקוח המנוי לא יכול לשלוח בקשות יוצאות.
אתם רוצים להשתמש באותו מופע כדי לעבד הודעות מנושאים וממינויים שונים, כשלקוח המנוי לא יודע את רשימת המינויים.
במקרים כלליים, מומלץ להשתמש בספריית הלקוח ברמה גבוהה. אם אתם משתמשים במשיכה אוניטרית, אל תגדירו את returnImmediately ל-true. הגדרה של הערך true משפיעה לרעה על ביצועי השליפה.
השדה returnImmediately הוצא משימוש.
כדי להשוות בין כל סוגי המינויים ולבחור את המינוי שהכי מתאים לצרכים העסקיים שלכם, אפשר לעיין בטבלת ההשוואה של המינויים ל-Pub/Sub.
כדי לקרוא על היתרונות של מינוי לייצוא, אפשר לעיין במאמר מתי כדאי להשתמש במינוי לייצוא.
עיבוד הודעות לפני אישור קבלתן
כברירת מחדל, מערכת Pub/Sub משליכה הודעה ממינוי אחרי שההודעה מאושרת. אם לא מעבדים הודעה לפני ששולחים אישור והעיבוד נכשל, השירות לא ישלח מחדש את ההודעה. היוצא מן הכלל הוא אם הגדרתם שמירה של הודעות שאושרה קבלתן או שמירה של נושא, ואתם מבצעים פעולת חיפוש.
אם יש לכם מנויים עם זמן אחזור גבוה, יכול להיות שתצטרכו להגדיר ערכים בהתאמה אישית עבור בקרה על זרימת נתונים וניהול חכירה.
הגדרת בקרה על זרימת נתונים של אפליקציות רשומות לעליות זמניות בתעבורת נתונים
בצד המנוי, בקרה על זרימת נתונים מאפשרת למנויים למנוע עומס יתר של תעבורת נתונים. הוא יכול לאפשר למנגנוני התאמה אוטומטית לעומס להגיב לעומס מוגבר, או לפזר את העיבוד של העומס על פני תקופה ארוכה יותר. השיטה הראשונה חוסכת זמן אחזור, והשיטה השנייה חוסכת עלויות.
כדי להגדיר בקרה על זרימת נתונים, צריך להגדיר ערכים מתאימים ל-maximum outstanding messages ול-total outstanding message bytes. ערכי ברירת המחדל של משתני בקרה על זרימת נתונים אלה ושמות המשתנים עשויים להיות שונים בספריות לקוח שונות.
Maximum outstanding messages (מספר מקסימלי של הודעות שלא נשלחו) מגדיר את המספר המקסימלי של הודעות שנמסרו ללקוח, שלא התקבלו לגביהן אישורים או אישורים שליליים ב-Pub/Sub.
הגודל הכולל המקסימלי של הודעות שלא נשלחו מגדיר את הגודל הכולל המקסימלי של הודעות שנמסרו ללקוח, ושלא התקבלו לגביהן אישורים או אישורים שליליים ב-Pub/Sub.
אם חורגים מהמגבלה של אחת מהאפשרויות האלה, לקוח המינוי לא ימשוך יותר הודעות. ההתנהגות הזו נמשכת עד שההודעות שכבר נמשכו מקבלות אישור או אישור שלילי. כך תוכלו להגיע לאיזון בין התפוקה לבין העלות שמשויכת להפעלת יותר מנויים.
טיפול במשלוחים כפולים
כברירת מחדל, ב-Pub/Sub יש אפשרות של לפחות מסירה אחת של הודעות למנויים. כלומר, יכול להיות שהודעות יימסרו כמה פעמים, גם אם הן אושרו. בקטעים הבאים נסביר איך לטפל בתרחישים נפוצים של מסירה חוזרת.
מסירה חוזרת עקבית של הרבה הודעות
אם אתם נתקלים במקרים שבהם הרבה הודעות נשלחות מחדש באופן קבוע, יכול להיות שהמנויים שלכם מוצפים או שהם לא מאשרים את ההודעות לפני שהמועד האחרון פג.
אם אתם משתמשים במינוי מסוג pull, יכול להיות שתצטרכו להגדיר ערכים מותאמים אישית לערכי בקרה על זרימת נתונים או להגדיל את תקופות הארכת החכירה באמצעות ניהול חכירה.
אם אתם משתמשים במינויים לקבלת הודעות פוש, יכול להיות שתצטרכו להגדיל את הגדרת תאריך היעד לאישור. אפשר גם לפעול לפי השיטות המומלצות לתחזוקה של מינוי תקין.
מסירה חוזרת של הודעות מדי פעם
אם אתם רואים שההודעות נשלחות מחדש לפני שחלף המועד האחרון לאישור או אחרי שההודעות אושרו תוך כמה שניות, המערכת של Pub/Sub פועלת כמצופה. לא אמורים לראות שיאים של מסירה מחדש לעיתים קרובות, אבל כשמתבצעות מסירות מחדש, סביר להניח שהן יתבצעו בכמה הודעות בו-זמנית. המערכת שלכם צריכה להיות בנויה כך שתהיה סובלנית כלפי הכפילויות האלה מדי פעם.
מספר הודעות נשלחות מחדש שוב ושוב
אם אתם רואים מספר קטן של הודעות שנמסרו כמה פעמים, קודם צריך לוודא שאתם מאשרים את קבלתן. אם לא, צריך להבין למה המנוי לא מטפל בהודעות כמו שצריך. כדאי להגדיר נושא של הודעות שלא נמסרו כדי למנוע מסירה חוזרת נוספת. אם אתם מאשרים את ההודעה, יכול להיות ש-Pub/Sub עדיין פועל כצפוי. במקרים נדירים מאוד, יכול להיות שמספר קטן של הודעות יימסרו כמה פעמים אם יש שיבושים פנימיים ברשת או בחומרה. במקרים כאלה, השירות מנסה לתקן את עצמו, אבל יכולות לעבור כמה דקות עד שהתיקונים יופעלו.
המערכת צריכה להיות סובלנית למסירות חוזרות. כדי להקטין את הסיכויים לכך, חשוב לעבד את ההודעות ולאשר את קבלתן במהירות האפשרית.
אם האפליקציה שלכם לא יכולה לסבול כפילויות, אתם יכולים להפעיל מסירה בדיוק פעם אחת. חשוב לזכור שהתכונה הזו זמינה רק למינויים מסוג pull, ושהיא גם גורמת לזמן אחזור ארוך יותר בין פרסום למינוי. לפני שמפעילים את התכונה הזו, חשוב לבדוק אם העלייה בחביון מקובלת לתרחיש השימוש שלכם.
שיטות מומלצות להעברת הודעות מסודרות בהרשמה
אם אתם משתמשים בהזמנת הודעות, חשוב לוודא את הדברים הבאים:
בוחרים באפשרות StreamingPull או באפשרות Pull subscriptions. במינוי מסוג push, Pub/Sub תומך רק בהודעה אחת שלא נשלחה לכל מפתח הזמנה בכל פעם. שליחת בקשות push מקבילות בתרחיש כזה תהיה דומה לשליחת כמה קבוצות של הודעות עם אותו מפתח הזמנה כדי למשוך מנויים בו-זמנית. לכן לא מומלץ להשתמש במינויים מסוג push לנושאים שבהם מתפרסמות לעיתים קרובות כמה הודעות עם אותו מפתח סדר, או לנושאים שבהם זמן האחזור חשוב במיוחד.
מפעילים את האפשרות להזמנת הודעות במינוי. בצד בעל התוכן הדיגיטלי, אם שולחים הודעות עם מפתח הזמנה ובאותו אזור, אפשר להגדיר את המנויים לקבל את ההודעות האלה לפי הסדר. בצד המנוי, מפעילים את מאפיין סידור ההודעות רק עבור המינויים שרוצים לקבל עבורם הודעות מסודרות. בהתאם לסטטוס של הנכס, כל מינוי שמצורף לנושא יכול לקבוע אם הוא צריך מסירה מסודרת, בלי להשפיע על מינויים אחרים.
אישור קריאה של הודעות לפי הסדר. כשמשתמשים באפשרות 'מסירה לפי סדר', אישורים להודעות מאוחרות יותר לא מעובדים עד שאישורים להודעות קודמות מעובדים לפי מפתח ההזמנה. לדוגמה, אם יש לכם הודעות 1, 2 ו-3 עם אותו מפתח סידור, קיבלתם את כולן ואישרתם רק את הודעה 3, השירות לא יתייחס להודעה 3 כמאושרת עד שתאשרו גם את הודעות 1 ו-2. אם לא מתקבלות אישורי המסירה של הודעות 1 ו-2, כל ההודעות (1, 2 ו-3) נשלחות מחדש.
סיכום השיטות המומלצות
בטבלה הבאה מפורטות השיטות המומלצות שמופיעות במסמך הזה:
| נושא | משימה |
|---|---|
| בחירת סוג המינוי | בוחרים את סוג המינוי שמתאים לצרכים של העסק. אם המינוי שלכם תומך בכך, כדאי להשתמש גם בספריית הלקוח ברמה הגבוהה. |
| הפעלה מחדש של הודעה שאושרה | לעבד הודעה לפני שמאשרים אותה. אפשר גם להגדיר פעולת חיפוש כדי לא לאבד הודעות שאושרו. |
| בקרה על זרימת נתונים | כדי לוודא שהאפליקציות הרשומות לא יהיו עמוסות מדי עד שההתאמה האוטומטית לעומס תתחיל לפעול או עד שיעבור זמן, צריך להגדיר בקרה על זרימת נתונים בהגדרות האפליקציות הרשומות. |
| הזמנת הודעות | כשמשתמשים בהעברת הודעות לפי סדר, צריך לבחור באפשרות StreamingPull או Pull, להפעיל את האפשרות message ordering (העברת הודעות לפי סדר) במינוי ולאשר את ההודעות לפי הסדר. |