سواء كنت تعمل على تطوير تطبيق جديد أو تدير خدمة عالية الزيارات، يمكنك الاستفادة من الإحصاءات والاقتراحات الواردة في هذا الدليل حول كيفية توسيع نطاق استخدام خدمة المراسلة عبر السحابة الإلكترونية 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 ألف طلب في الثانية على مستوى العالم من واجهة برمجة تطبيقات 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 ألف طلب في الثانية على مستوى العالم أو 30 ألف طلب في الثانية على مستوى القارة.