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

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

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

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

טיפול באירועים על סמך התגובה שמתקבלת מהפרסום

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

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

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

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

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

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

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

יש שני סוגים של השהיות ב-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 בניסיון החוזר השני, ועד 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 אזורים שאתם מציינים, בלי קשר למקום שממנו מגיעות בקשות הפרסום.

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

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

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

שיטות מומלצות להצגת הודעות בסדר מסוים במוצרי Google

אם אתם משתמשים בהזמנת הודעות, חשוב לוודא את הדברים הבאים:

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

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

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

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

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

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