سواء كنت تعمل على تطوير تطبيق جديد أو تشغّل حاليًا خدمة ذات عدد كبير من الزيارات، يمكنك الاستفادة من الإحصاءات والاقتراحات الواردة في هذا الدليل حول كيفية توسيع نطاق استخدام خدمة المراسلة عبر السحابة الإلكترونية 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: يجب إعادة محاولة إرسال الطلب باستخدام خوارزمية الرقود الأسي الثنائي.
خوارزمية الرقود الأسي الثنائي
لتجنُّب تضخيم عمليات إعادة المحاولة، يجب تنفيذ خوارزمية الرقود الأسي الثنائي مع التأخير العشوائي لإعادة محاولة إرسال الطلبات. على سبيل المثال، تنفّذ حزمة تطوير البرامج (SDK) لمشرف Firebase خوارزمية الرقود الأسي الثنائي.
في ما يلي بعض الإعدادات الأخرى المقترَحة:
- الفاصل الزمني الأدنى: يجب عدم إعادة محاولة إرسال طلب تعذّر إرساله على الفور باستخدام خدمة المراسلة عبر السحابة الإلكترونية 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 ساعات. |
خطة العودة إلى الحالة السابقة الافتراضية:
- إذا زاد وقت الاستجابة في المئوي الخامس والتسعين عن 500 ملّي ثانية أو إذا تجاوز معدّل الخطأ% 1 لأكثر من ساعة في أي خطوة، يمكنك استخدام الإعدادات الديناميكية للتراجع إلى الخطوة السابقة على الفور.
- يجب مواصلة عمليات التراجع إلى خطوات سابقة حتى يعود وقت الاستجابة ومعدّل الخطأ إلى المستويات العادية.
متى يجب التواصل مع فريق خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM)
يُرجى التواصل مع فريق خدمة المراسلة عبر السحابة الإلكترونية Firebase (FCM) من خلال فريق دعم Firebase إذا انطبق أي مما يلي:
- لم تعُد الحصص التلقائية تلبي حالة الاستخدام.
- أنت بصدد تغيير أنماط الإرسال خلال فترة 3 أشهر بمعدّل 100,000 طلب في الثانية على مستوى العالم أو 30,000 طلب في الثانية على مستوى القارة.