سواء كنت تعمل على تطوير تطبيق جديد أو تدير خدمة عالية الزيارات، يمكنك الاستفادة من الإحصاءات والاقتراحات الواردة في هذا الدليل حول كيفية توسيع نطاق استخدام خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) بسلاسة. يمكن أن تساعدك هذه المفاهيم والممارسات في تجنُّب الآثار السلبية عندما تحتاج إلى إرسال كميات كبيرة من الرسائل.
المصطلحات والمفاهيم الرئيسية
طلب محادثة: هو طلب رسالة في خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM)، ويُستخدَم بالتبادل مع "الطلب"، "الرسالة" أو "الاستعلام".
الطلبات في الثانية (RPS): هو مقياس لوصف معدّل الطلبات الواردة إلى خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM)، ويُستخدَم بالتبادل مع "الاستعلامات في الثانية" (QPS).
الرموز المميّزة للحصة، ومجموعات الرموز المميّزة، وعمليات إعادة التعبئة: عند إرسال الرسائل باستخدام الإصدار 1 من واجهة برمجة تطبيقات HTTP لخدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM)، يستهلك كل طلب رمزًا مميّزًا للحصة مخصّصًا له في فترة زمنية معيَّنة. تتم إعادة تعبئة هذه الفترة، التي تُسمّى "مجموعة الرموز المميّزة"، بالكامل في نهاية الفترة الزمنية. على سبيل المثال، يخصّص الإصدار 1 من واجهة برمجة تطبيقات HTTP عدد 600 ألف رمز مميّز للحصة لكل مجموعة رموز مميّزة مدتها دقيقة واحدة، وتتم إعادة تعبئتها بالكامل في نهاية كل فترة مدتها دقيقة واحدة.
تقييد البيانات من جهة الخادم: عندما يتجاوز حجم الزيارات سعة خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM)
، يتم رفض الطلبات التي تتجاوز سعة العرض للحدّ من معدّل تدفق البيانات الواردة. قد يتم عرض ردود الأخطاء 429 التي تتضمّن عناوين retry-after للإشارة إلى أنّه عليك الانتظار لفترة زمنية معيّنة قبل إعادة محاولة إرسال الطلب.
تقييد البيانات من جهة العميل: عندما يلاحظ العملاء حالات تعذّر إرسال الطلبات أو ارتفاع وقت الاستجابة،
أو ظهور أخطاء 429، عليهم الحدّ طوعًا من معدّل تدفق البيانات الصادرة لتجنُّب تفاقم
الازدحام.
**خوارزمية الرقود الأسي الثنائي**: عند إعادة محاولة إرسال الطلبات التي تسبّبت في حدوث أخطاء، يجب إضافة تأخيرات زمنية متزايدة بشكل أسي. على سبيل المثال: ثانية واحدة، ثانيتان، 4 ثوانٍ، 8 ثوانٍ، 16 ثانية، 32 ثانية، وما إلى ذلك.
التأخير العشوائي: هو تجنُّب إعادة محاولة إرسال الطلبات في فواصل زمنية دقيقة. باستخدام التأخير العشوائي، يمكنك تغيير فترات التأخير لإعادة المحاولة من خلال عملية عشوائية لتوزيعها بشكل منتظم بمرور الوقت (على سبيل المثال: 0.9 ثانية، 2.3 ثانية، 4.1 ثانية، 8.5 ثانية، 17.9 ثانية، 34.7 ثانية).
تضخيم عمليات إعادة المحاولة: عندما تتم إعادة محاولة إرسال الطلبات التي تعذّر إرسالها بدون استخدام خوارزمية الرقود الأسي الثنائي أو التأخير العشوائي، غالبًا ما تتراكم هذه الطلبات وتزيد من حمل الزيارات المستمر، ما قد يؤدي إلى "تضخيم" مشاكل ازدحام الزيارات وتفاقمها.
المشكلة: الارتفاعات المفاجئة في عدد الزيارات
تعالج خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) ملايين الطلبات في الثانية (RPS). والعامل الأكبر الذي يساهم في الازدحام المنهجي ومشاكل وقت الاستجابة والانقطاعات هو الارتفاعات المفاجئة في عدد الزيارات.
ما هي الزيارات التي تشهد ارتفاعات مفاجئة؟
هناك أنواع مختلفة من الارتفاعات المفاجئة في عدد الزيارات.
الارتفاعات المفاجئة في بداية الساعة: تتلقّى خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) أكثر من ضعف عدد الزيارات خلال أول 30 ثانية إلى دقيقتَين من كل ساعة. تُلاحَظ أيضًا ارتفاعات مفاجئة مماثلة، وإن كانت أقل، في علامات منتصف الساعة وربع الساعة (أمثلة: 00:15 و00:30 و00:45).
تضخيم عمليات إعادة المحاولة: يمكن أن تتراكم عمليات إعادة محاولة إرسال الطلبات التي تعذّر إرسالها أو التي انتهت مهلتها بدون استخدام خوارزمية الرقود الأسي الثنائي لتشكّل موجات متكرّرة من الزيارات فوق قمم الزيارات الحالية.
التغييرات المفاجئة في أنماط الزيارات: يمكن أن يؤدي توجيه زيارات جديدة إلى خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) أو نقل الزيارات إلى خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) في مناطق مختلفة بدون عوامل تسهيل، مثل زيادة عدد الزيارات تدريجيًا، إلى حدوث ارتفاعات مفاجئة.
الاستخدام المبكر لرموز حصة الاستخدام: سيؤدي استنفاد جميع رموز حصة الاستخدام في بداية فترات الحصة بدلاً من توزيع الطلبات بالتساوي على فترات الحصة إلى حدوث تذبذبات متقطّعة يصعب موازنة الحمل فيها وتكون مكلفة.
الأحداث الخاصة: تحدث ارتفاعات مفاجئة في عدد الزيارات خلال العطلات (ليلة رأس السنة) أو الأحداث الرياضية (كأس العالم لكرة القدم).
علاج الارتفاعات المفاجئة في عدد الزيارات من خلال "تسطيح المنحنى"
يصف هذا القسم استراتيجيات لتسهيل الارتفاعات المفاجئة في عدد الزيارات حيثما أمكن، وهي استراتيجيات "تسطيح المنحنى".
استخدام FCM لحالات الاستخدام المناسبة فقط
هناك بعض حالات الاستخدام التي لا يكون فيها استخدام خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) لإرسال إشعار ضروريًا أو مناسبًا.
على سبيل المثال، بالنسبة إلى إشعارات أحداث التقويم، يمكنك جدولة مهمة محلية في تطبيقك لعرض إشعار في الأوقات المناسبة بدلاً من إرساله من خادم تطبيقك. يمكنك حصر رسائل خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) في عمليات مزامنة التقويم.
تجنُّب الارتفاعات المفاجئة
أحد الأنماط المضادة لتوسيع النطاق هو إرسال إشعارات خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) بأسرع ما تسمح به الأنظمة، بدلاً من تطبيق تقييد البيانات من جهة الخادم. يُرجى مراعاة ما يلي:
- هل يحتاج جميع عملاؤك إلى تلقّي الإشعار نفسه خلال فترة دقيقة واحدة؟ هل ستظل فترة التسليم التي تبلغ 5 دقائق، على سبيل المثال، تلبي احتياجات مؤسستك؟
- هل يمكن تصنيف العملاء استنادًا إلى الأولوية لتسهيل الارتفاعات المفاجئة؟
- هل يمكن جدولة الإشعارات مسبقًا؟
حيثما أمكن: تجنَّب الاستراتيجيات التي تؤدي إلى استنفاد حصة الإرسال في خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) على الفور، ثم تكرار النمط بمجرد إعادة تعبئة مجموعة الرموز المميّزة. يؤدي نمط الوصول هذا إلى حدوث مشاكل في موازنة الحمل لخدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) والأنظمة التابعة لها. يجب زيادة عدد الزيارات تدريجيًا قدر الإمكان. كحدّ أدنى، يجب زيادة عدد الزيارات من 0 إلى الحد الأقصى للطلبات في الثانية خلال فترة زمنية مدتها 60 ثانية. يُفضَّل استخدام فترات أطول لعدد أكبر من الطلبات في الثانية.
تجنُّب الزيارات "في بداية الساعة"
حيثما أمكن: تجنَّب إرسال الرسائل خلال فترة دقيقتَين من كل من علامات الدقائق :00 و:15 و:30 و :45.
تنفيذ تقييد البيانات من جهة الخادم
نفِّذ تقييد البيانات من جهة الخادم لمراقبة تدفق الزيارات إلى خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) وإدارته.
التعامل مع عمليات إعادة المحاولة
على الرغم من أنّ خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) تسعى إلى توفير درجة عالية من التوفّر، ستنتهي مهلة بعض الطلبات أو سيتعذّر إرسالها في بعض الأحيان. على الرغم من أنّ الأسباب تختلف، فإنّ أفضل الممارسات التالية تحسِّن سلوك إعادة المحاولة لإرسال الرسائل في أقرب وقت ممكن مع تقليل التأثير في ازدحام الزيارات إلى أدنى حد.
المهلات
يجب ضبط مهلة لا تقل عن 10 ثوانٍ لطلبات الإرسال قبل إعادة المحاولة. تستخدم معظم طلبات الإجراء عن بُعد الداخلية في خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) مهلة تبلغ 10 ثوانٍ.
الأخطاء
- بالنسبة إلى الأخطاء 400 و401 و403 و404: يجب إلغاء الطلب وعدم إعادة محاولة إرساله.
- بالنسبة إلى الأخطاء 429: يجب إعادة محاولة إرسال الطلب بعد الانتظار للمدة المحدّدة في عنوان `retry-after`. إذا لم يتم ضبط عنوان `retry-after`، يتم استخدام 60 ثانية كقيمة تلقائية.
- بالنسبة إلى الأخطاء 500: يجب إعادة محاولة إرسال الطلب باستخدام خوارزمية الرقود الأسي الثنائي.
خوارزمية الرقود الأسي الثنائي
لتجنُّب تضخيم عمليات إعادة المحاولة، يجب تنفيذ خوارزمية الرقود الأسي الثنائي مع التأخير العشوائي لإعادة محاولة إرسال الطلبات. على سبيل المثال، تنفّذ حزمة Firebase Admin SDK خوارزمية الرقود الأسي الثنائي.
في ما يلي بعض الإعدادات الأخرى المقترَحة:
- الفاصل الزمني الأدنى: يجب عدم إعادة محاولة إرسال طلب تعذّر إرساله على الفور باستخدام خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM). يجب الانتظار 10 ثوانٍ على الأقل قبل إعادة محاولة إرسال طلب تعذّر إرساله.
- الفاصل الزمني الأقصى: يجب ضبط فاصل زمني أقصى لإسقاط الطلبات التي لم تعُد في وقتها، بدلاً من إعادة محاولة إرسالها إلى أجل غير مسمّى.
إذا تمت إعادة محاولة إرسال طلب بشكل مستمر باستخدام خوارزمية الرقود الأسي الثنائي وكان لا يزال يتعذّر إرساله بعد 60 دقيقة، يعني ذلك أنّه تم تصنيفه بشكل خاطئ كخطأ قابل لإعادة المحاولة، أو أنّ خدمة مراسلة Firebase السحابية (FCM) تواجه انقطاع الخدمة قد يؤدي فيه إعادة المحاولات إلى تفاقم الوضع عن غير قصد.
إنشاء خطط الطرح والعودة إلى الحالة السابقة وإجراء تغييرات تدريجية
عند إجراء تغييرات كبيرة على الزيارات، مثل زيادة عدد الزيارات إلى مراسلة Firebase السحابية (FCM) أو نقل الزيارات بين مناطق أو شبكات مختلفة، سيؤدي تصميم خطة طرح/العودة إلى الحالة السابقة وتنفيذ تغييرات تدريجية إلى حماية المستخدمين والخدمة ومراسلة Firebase السحابية (FCM).
- تتوافق خطة النشر مع توقّعات أصحاب المصلحة. في حالات معيّنة (تتم مناقشتها أدناه)، قد يكون من المفيد مشاركة خطة النشر مسبقًا مع فريق خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) لتجنُّب المفاجآت.
- تسمح لك خطة التراجع بمراعاة الحالات الطارئة وإعداد آليات للاسترداد السريع والآمن من حالات الإخفاق غير المتوقّعة.
- يتضمّن إجراء تغييرات تدريجية جانبَين:
- عمليات زيادة عدد الزيارات "خطوة بخطوة": يجب أن تكون الخطوات 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% أو أدق. "اختبار" (مراقبة سلوك النظام تحت الحمل) كل خطوة لمدة تتراوح بين يوم واحد وأسبوع واحد. يسمح لك ذلك برصد المشاكل المحتملة قبل "الخطوة التالية".
- عمليات زيادة عدد الزيارات تدريجيًا: عند اتخاذ كل "خطوة" لزيادة عدد الزيارات، يجب تسهيل الزيارات على مدار ساعة واحدة على الأقل. يسمح ذلك للبنية الأساسية لموازنة الحمل في خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) بتوسيع نطاق الزيارات الجديدة بشكل مناسب مع تقليل احتمالية حدوث نقاط ساخنة وازدحام إلى أدنى حد.
في ما يلي سيناريو افتراضي لنقل 500,000 طلب في الثانية على مستوى العالم من الإصدار القديم من واجهة برمجة تطبيقات HTTP لخدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) إلى الإصدار 1 من واجهة برمجة تطبيقات HTTP لخدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM):
| أسبوع | Step | استراتيجية الزيادة التدريجية |
|---|---|---|
| 0 | زيادة عدد الزيارات بنسبة% 1 | يجب زيادة عدد الزيارات بسلاسة من 0 إلى 5,000 طلب في الثانية إلى الإصدار 1 من واجهة برمجة تطبيقات HTTP لخدمة مراسلة Firebase السحابية (FCM) على مدار ساعة. |
| 1 | زيادة عدد الزيارات بنسبة% 5 | يجب زيادة عدد الزيارات بسلاسة من 5,000 إلى 25,000 طلب في الثانية على مدار ساعتَين. |
| 2 | زيادة عدد الزيارات بنسبة% 10 | يجب زيادة عدد الزيارات بسلاسة من 25,000 إلى 50,000 طلب في الثانية على مدار ساعتَين. |
| 3 | زيادة عدد الزيارات بنسبة% 25 | يجب زيادة عدد الزيارات من 50,000 إلى 125,000 طلب في الثانية على مدار 3 ساعات. |
| 4 | زيادة عدد الزيارات بنسبة% 50 | يجب زيادة عدد الزيارات من 125,000 إلى 250,000 طلب في الثانية على مدار 6 ساعات. |
| 5 | زيادة عدد الزيارات بنسبة% 75 | يجب زيادة عدد الزيارات من 250,000 إلى 375,000 طلب في الثانية على مدار 6 ساعات. |
| 6 | زيادة عدد الزيارات بنسبة% 100 | يجب زيادة عدد الزيارات من 375,000 إلى 500,000 طلب في الثانية على مدار 6 ساعات. |
خطة العودة إلى الحالة السابقة الافتراضية:
- إذا زاد وقت الاستجابة في المئوي الـ 95 عن 500 مللي ثانية أو إذا تجاوز معدّل الخطأ% 1 لأكثر من ساعة في أي خطوة، يجب استخدام الإعدادات الديناميكية للتراجع إلى الخطوة السابقة على الفور.
- يجب مواصلة عمليات التراجع إلى الخطوات السابقة إلى أن يعود وقت الاستجابة ومعدّل الخطأ إلى المستويات العادية.
متى يجب التواصل مع فريق خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM)
يُرجى التواصل مع فريق خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) من خلال فريق دعم Firebase في أي من الحالات التالية:
- لم تعُد الحصص التلقائية تلبي حالة الاستخدام
- يتم تغيير أنماط الإرسال خلال فترة 3 أشهر بمعدّل 100,000 طلب في الثانية على مستوى العالم أو 30,000 طلب في الثانية على مستوى القارة.