שיטות מומלצות לפרסום בנושא Pub/Sub

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

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

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

מבצעים פעולה על סמך התגובה מהפרסום

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

  • מתעדים את השגיאה ביומן ולא עושים שום דבר אחר (אם תרחיש השימוש שלכם לא דורש פרסום מוצלח של כל ההודעות).
  • לנסות שוב לפרסם במקרה של כשל זמני, כמו שגיאת Deadline exceeded.
  • שומרים את ההודעה בקובץ או באחסון כדי לנסות לפרסם אותה שוב מאוחר יותר, במיוחד במקרה של שגיאה שדורשת התערבות של המשתמש, כמו Not found או Permission denied.
  • להפיץ את השגיאות לשירות במעלה הזרם ששלח את ההודעה שניסיתם לפרסם.

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

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

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

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

לפני שמתחילים לפרסם, צריך לצרף מינוי או להפעיל שמירת נושאים.

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

הגדרת העברת הודעות באצווה

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

יש שני סוגים של זמן אחזור ב-Pub/Sub:

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

  • זמן אחזור של פרסום הוא משך הזמן שלוקח לפרסם הודעה.

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

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

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

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

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

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

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

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

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

הסבר על רוחב הפס וזמן האחזור של הרשת

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

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

שינוי משתני הבקשה לניסיון חוזר של פרסומים שנכשלו

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

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

  • initialRetryDelay. ההשהיה הראשונית של בעל התוכן הדיגיטלי לפני ניסיון חוזר של פעולת פרסום. ערך ברירת המחדל הוא 100 milliseconds.

  • retryDelayMultiplier. מקדם הכפל שמשמש לחישוב ההשהיה בין הניסיונות החוזרים. ערך ברירת המחדל הוא 4. כלומר, ההשהיה בין הניסיונות החוזרים היא עד 100 milliseconds * 4 = 400 milliseconds לניסיון החוזר השני, ועד 400 milliseconds * 4 = 1600 milliseconds לניסיון החוזר השלישי.

  • maxRetryDelay. ההשהיה המקסימלית שהמפרסם ממתין לפני ניסיון חוזר של פעולת פרסום. ערך ברירת המחדל הוא 60 seconds.

  • initialRpcTimeout. הזמן הקצוב הראשוני לתפוגה שבעל האפליקציה ממתין עד להשלמת קריאת ה-RPC. ערך ברירת המחדל הוא 5 seconds.

  • rpcTimeoutMultiplier. מקדם הכפל שמשמש לחישוב הזמן הקצוב לתפוגה של ה-RPC. ערך ברירת המחדל הוא 4.0. כלומר, זמן הקצוב לתפוגה של קריאת ה-RPC הוא עד 5 seconds * 4 = 20 seconds לניסיון החוזר השני, ועד 10 seconds * 4 = 40 seconds לניסיון החוזר השלישי.

  • maxRpcTimeout. הזמן הקצוב המקסימלי שבעל האפליקציה ממתין להשלמת הקריאה ל-RPC. ערך ברירת המחדל הוא 600 seconds.

  • totalTimeout. הזמן הקצוב הכולל לפעולת הפרסום. הזמן הזה כולל את משך ההמתנה להשלמת קריאת ה-RPC ואת משך ההמתנה בין הניסיונות החוזרים. ערך ברירת המחדל הוא 600 seconds.

מומלץ לשנות את הערכים שצוינו רק אם הגדרות ברירת המחדל לניסיונות חוזרים לא מתאימות לתרחיש לדוגמה שלכם. לדוגמה, אם אתם מפרסמים מספר גדול של הודעות, לא תצטרכו להגדיל את הערכים של initialRetryDelay ו-maxRetryDelay. עם זאת, במקרים כאלה אפשר לשנות את בקרת הזרימה ואת העיבוד באצווה. אם אתם מפרסמים מחיבור לאינטרנט לא יציב או מחיבור עם רוחב פס מוגבל, אתם יכולים להתנסות בערכים של המשתנים initialRpcTimeout,‏ maxRpcTimeout ו-rpcTimeoutMultiplier. ערכים מומלצים מפורטים במאמר פעולות פרסום נכשלות עם השגיאה DEADLINE_EXCEEDED.

שימוש במדיניות אחסון ההודעות כדי להבטיח אחסון ועיבוד נתונים באופן מקומי

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

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

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

מידע נוסף זמין במאמר הגדרת כללי מדיניות לאחסון הודעות.

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

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

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

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

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

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

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

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