בין אם אתה מגדל אפליקציה בהתהוות או כבר מפעיל שירות עתיר תעבורה, אתה יכול ליהנות מהתובנות וההמלצות של מדריך זה כיצד לבצע קנה מידה חלק עם FCM. מושגים ונהלים אלה יכולים לעזור לך להימנע מהשפעות שליליות כאשר אתה צריך לשלוח כמויות גדולות של הודעות.
מונחים ומושגים מרכזיים
בקשת הודעה : בקשה להודעה של FCM; משמש להחלפה עם "בקשה", "הודעה" או "שאילתה".
בקשות לשנייה (RPS) : מדד לתיאור שיעור הבקשות הנכנסות ל-FCM; משמש להחלפה עם Queries-per-second (QPS).
אסימוני מכסה, דליים ומילוי חוזר : בעת שליחת הודעות מול FCM HTTP v1 API, כל בקשה צורכת אסימון מכסה שהוקצה בחלון זמן נתון. חלון זה, הנקרא " דלי אסימונים ", מתמלא מחדש עד תום חלון הזמן. לדוגמה: ה-API של HTTP v1 מקצה 600K Quota Tokens עבור כל דלי אסימונים של דקה, שמתמלא מחדש עד מלא בסוף כל חלון של דקה.
הגבלה בצד השרת : כאשר נפח התעבורה עולה על הקיבולת של שירות FCM, בקשות מעבר לקיבולת הגשה נדחות כדי להגביל את זרימת הכניסה. תגובות שגיאה 429 עם כותרות retry-after עשויות להיות מוחזרות כדי לציין שעליך להמתין פרק זמן נתון לפני שתנסה שוב את הבקשה.
גזירת צד לקוח : כאשר לקוחות רואים כשלים בבקשות, זמן אחזור גבוה או שגיאות 429 , עליהם להגביל מרצון את זרימת היציאה כדי להימנע מהחרפת הגודש.
גיבוי אקספוננציאלי : כאשר מנסים שוב שגיאות, הוסף עיכובי זמן הגדלים באופן אקספוננציאלי. לדוגמה: 1, 2, 4, 8, 16, 32.
ריצוד : הימנעות מניסיון חוזר של בקשות במרווחי זמן מדויקים. עם ריצוד, אתה משנה את עיכובי הניסיון החוזר באמצעות תהליך אקראי כדי להפיץ אותם באופן אחיד לאורך זמן (לדוגמה: 0.9 שניות, 2.3 שניות, 4.1 שניות, 8.5 שניות, 17.9 שניות, 34.7 שניות).
נסה שוב הגברה : כאשר בקשות שנכשלו מנוסים שוב ללא השבתה/ריצוד אקספוננציאלי, לעתים קרובות הן מצטברות ומוסיפות לעומס התעבורה המתמשך, מה שעלול להגביר ולהחמיר בעיות של עומסי תנועה.
הבעיה: עליות תנועה
FCM מעבד מיליוני בקשות בשנייה (RPS). התורם הגדול ביותר לגודש מערכתי, בעיות אחזור והפסקות הוא עליות תנועה.
מהי תעבורה דוקרנית?
ישנם מספר סוגים שונים של עליות תנועה.
עליות בשעה: FCM מקבל יותר מכפול תנועה במהלך 30 השניות הראשונות עד 2 דקות של כל שעה. דומים, אם כי פחות, עליות נצפים גם בסימני חצי שעה ורבע שעה (דוגמאות: 00:15, 00:30, 00:45)
נסה שוב הגברה : ניסיון חוזר של בקשות שנכשלו או פג הזמן הקצוב ללא השבתה אקספוננציאלית יכולה להצטבר לגלים חוזרים של תנועה על גבי פסגות תנועה קיימות.
שינויים פתאומיים בדפוס התנועה: הפניית תנועה חדשה ל-FCM או העברת תנועה ל-FCM בין אזורים ללא החלקה של גורמים כגון עלייה הדרגתית עלולה לגרום לעליות.
שימוש באסימוני מכסה בטעינה קדמית: מיצוי כל אסימוני המכסה בתחילת חלונות המכסה במקום לפזר את הבקשות באופן שווה על פני חלונות המכסה תיצור תנודות לסירוגין שקשה ויקר לאיזון עומס.
אירועים מיוחדים: עליות תנועה במהלך חגים (ערב ראש השנה) או אירועי ספורט ( מונדיאל FIFA ).
תקן עליות תנועה על ידי "השטחת העקומה"
סעיף זה מתאר אסטרטגיות להחליק עליות תנועה במידת האפשר - אסטרטגיות "לשטח את העקומה".
השתמש ב-FCM רק עבור מקרי שימוש מתאימים
ישנם מקרים מסוימים שבהם שימוש ב-FCM להעברת הודעה אינו הכרחי או מתאים.
לדוגמה, עבור התראות על אירועי יומן, אתה יכול לתזמן משימה מקומית באפליקציה שלך כדי להציג התראה בזמנים המתאימים במקום לשלוח אותה משרת האפליקציה שלך. הגבל הודעות FCM לסנכרון לוח שנה.
הימנע מקוצים
אנטי-דפוס קנה מידה אחד הוא לשלוח הודעות FCM מהר ככל שהמערכות יאפשרו, במקום להחיל מצערת בצד השרת. שקול את הדברים הבאים:
- האם כל הלקוחות שלך צריכים לקבל את אותה התראה תוך חלון של דקה אחת? האם חלון משלוח של 5 דקות, למשל, עדיין יענה על הצרכים העסקיים שלך?
- האם ניתן לפלח את הלקוחות שלך על סמך עדיפות להחליק מעל הקוצים?
- האם ניתן לתזמן את ההתראות שלך מבעוד מועד?
בכל מקום אפשרי : הימנע מאסטרטגיות שמביאות למיצוי מיידי של מכסת השליחה של FCM שלך, רק כדי לחזור על הדפוס ברגע שדלי האסימונים שלך מתמלא מחדש. דפוס גישה זה יוצר בעיות איזון עומסים עבור FCM והמערכות התלויות בו. הגבירו את התנועה בהדרגה ככל האפשר. לכל הפחות, הפוך מ-0 ל-RPS המקסימלי על פני חלון זמן של 60 שניות. העדיפו חלונות ארוכים יותר עבור RPS גבוה יותר.
הימנע מתנועה "בשעה".
במידת האפשר : הימנע משליחת הודעות בתוך חלון של 2 דקות מכל אחד מהסימנים :00, :15, :30 ו-:45 דקות.
הטמעו החסות בצד השרת
הטמע גזירה בצד השרת כדי לנטר ולנהל את זרימת התעבורה ל-FCM.
טיפול בניסיונות חוזרים
בעוד ש-FCM שואפת להיות זמינה גבוהה, לפעמים חלק מהבקשות יפסיקו או ייכשלו. למרות שהסיבות משתנות, השיטות המומלצות הבאות מייעלות את התנהגות הניסיון החוזר כדי להעביר הודעות בהקדם האפשרי תוך מזעור ההשפעה על עומסי התנועה.
פסקי זמן
הגדר לפחות 10 שניות זמן קצוב על שליחה של בקשות לפני ניסיון חוזר. רוב השיחות הפנימיות להליך מרחוק של FCM משתמשות בפסק זמן של 10 שניות.
שגיאות
- עבור שגיאות 400, 401, 403, 404: בטל, ואל תנסה שוב.
- עבור שגיאות 429: נסה שוב לאחר המתנה למשך הזמן שנקבע בכותרת ניסיון חוזר לאחר. אם לא מוגדרת כותרת ניסיון חוזר לאחר, ברירת המחדל היא 60 שניות.
- עבור 500 שגיאות: נסה שוב עם השבתה מעריכית.
גיבוי אקספוננציאלי
כדי להימנע מהגברה חוזרת, הטמיע גיבוי אקספוננציאלי עם ריצוד לניסיון חוזר של בקשות. ה-SDK של Firebase Admin, למשל, מיישמת גיבוי אקספוננציאלי.
הנה עוד כמה הגדרות מומלצות:
- מרווח מינימלי: אל תנסה מיד שוב בקשה שנכשלה עם FCM. המתן לפחות 10 שניות לפני שתנסה שוב בקשה שנכשלה.
- מרווח מרבי: הגדר מרווח מרבי לביטול בקשות שכבר אינן בזמן, במקום לנסות שוב ללא הגבלת זמן.
אם בקשה מנוסה שוב ושוב עם השבתה אקספוננציאלית ועדיין נכשלת כעבור 60 דקות, היא מסווגת בצורה שגויה כשגיאה שניתנת לניסיון חוזר, או ש-FCM חווה הפסקה שבה ניסיונות חוזרים עלולים להחמיר את המצב בטעות.
צור תוכניות השקה והחזרה, ובצע שינויים הדרגתיים
בעת ביצוע שינויים בתנועה בקנה מידה גדול, כגון הגדלת תעבורה ל-FCM או העברת תעבורה בין אזורים או רשתות, עיצוב תוכנית השקה/החזרה והטמעת שינויים הדרגתיים יגנו על המשתמשים שלך, על השירות שלך ועל FCM.
- תוכנית השקה מיישרת ציפיות לבעלי עניין. במצבים מסוימים (עליהם נדון בהמשך), ייתכן שתרצה לשתף את תוכנית ההשקה שלך מבעוד מועד עם צוות FCM כדי למנוע הפתעות.
- תוכנית החזרה לאחור מאפשרת לך לתת דין וחשבון למקרים ולהכין מנגנונים להתאוששות מהירה ובטוחה מתקלות בלתי צפויות.
- לביצוע שינויים הדרגתיים יש שני היבטים:
- עליות "שלביות": הצעדים צריכים להיות 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% או עדין יותר. " השרי " (התבונן בהתנהגות המערכת תחת עומס) כל שלב למשך יום אחד עד שבוע. זה מאפשר לך לזהות בעיות פוטנציאליות לפני ה"עלייה" הבאה
- התגברות תנועה הדרגתית: כאשר עושים כל "צעד" כדי להגביר את התנועה, החלק את התנועה על פני שעה לפחות. זה מאפשר לתשתית איזון העומס של FCM להתאים את התעבורה החדשה שלך תוך מזעור הפוטנציאל לנקודות חמות וגודש.
להלן תרחיש היפותטי להעברת 500,000 RPS גלובלית מ-FCM Legacy HTTP API ל-FCM HTTP v1 API:
| שָׁבוּעַ | שלב | אסטרטגיית התגברות הדרגתית |
|---|---|---|
| 0 | עלייה של 1%. | הגדל בצורה חלקה מ-0 ל-5,000 RPS ל-FCM HTTP v1 במהלך שעה. |
| 1 | עלייה של 5%. | התגבר בצורה חלקה מ-5,000 ל-25,000 RPS במשך שעתיים. |
| 2 | עלייה של 10%. | העלאה חלקה מ-25,000 ל-50,000 RPS במשך שעתיים |
| 3 | עלייה של 25%. | העלאה מ-50,000 ל-125,000 RPS במשך 3 שעות |
| 4 | התגברות של 50%. | העלאה מ-125,000 ל-250,000 RPS במשך 6 שעות |
| 5 | עלייה של 75%. | העלאה מ-250,000 ל-375,000 RPS במשך 6 שעות |
| 6 | 100% התגברות | העלאה מ-375,000 ל-500,000 RPS במשך 6 שעות |
תוכנית החזרה היפותטית:
- אם זמן האחזור של 95 אחוזים עולה ליותר מ-500 אלפיות השנייה או אם יחס השגיאה עולה על 1% במשך יותר משעה בכל שלב, השתמש בתצורה דינמית כדי לחזור מיד לשלב הקודם.
- המשך בהחזרה לשלבים קודמים עד שהשהייה ויחס השגיאות יחזרו לרמות נומינליות.
מתי לפנות ל-FCM
צור קשר עם FCM דרך התמיכה של Firebase אם חל אחד מהדברים הבאים:
- מכסות ברירת המחדל כבר אינן עומדות במקרה השימוש שלך
- אתה משנה את דפוסי השליחה שלך בתוך חלון של 3 חודשים בקנה מידה של 100,000 RPS ברחבי העולם או 30,000 RPS יבשתית.