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

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

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

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

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

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

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

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