سواء كنت تعمل على تطوير تطبيق ناشئ أو تدير خدمة ذات عدد زيارات كبير، يمكنك الاستفادة من الإحصاءات والاقتراحات الواردة في هذا الدليل حول كيفية توسيع نطاق استخدام "مراسلة Firebase السحابية" بسلاسة. يمكن أن تساعدك هذه المفاهيم والممارسات في تجنُّب التأثيرات السلبية عند الحاجة إلى إرسال كميات كبيرة من الرسائل.
المصطلحات والمفاهيم الرئيسية
طلب رسالة: طلب رسالة من خلال خدمة "مراسلة Firebase السحابية"؛ ويُستخدم بالتبادل مع "طلب" أو "رسالة" أو "طلب بحث".
الطلبات في الثانية (RPS): مقياس لوصف معدّل الطلبات الواردة إلى FCM، ويُستخدم بالتبادل مع "طلبات البحث في الثانية" (QPS).
الرموز المميّزة للحصة وحِزم الرموز المميّزة وإعادة التعبئة: عند إرسال رسائل إلى الإصدار 1 من واجهة برمجة تطبيقات HTTP لمراسلة Firebase السحابية، يستهلك كل طلب رمزًا مميّزًا للحصة مخصّصًا في فترة زمنية معيّنة. هذه النافذة، التي تُسمى "حزمة الرموز المميزة"، تتم إعادة تعبئتها بالكامل في نهاية النافذة الزمنية. على سبيل المثال: تمنح واجهة HTTP v1 API 600 ألف رمز مميّز للحصة لكل حزمة رموز مميّزة مدتها دقيقة واحدة، وتتم إعادة تعبئتها بالكامل في نهاية كل دقيقة.
التقييد من جهة الخادم: عندما يتجاوز حجم الزيارات سعة خدمة FCM، يتم رفض الطلبات التي تتجاوز سعة العرض للحدّ من معدّل تدفق البيانات الواردة. قد يتم عرض استجابات الخطأ 429 مع عناوين retry-after للإشارة إلى أنّه عليك الانتظار لفترة زمنية معيّنة قبل إعادة محاولة إرسال الطلب.
الحدّ من الطلبات من جهة العميل: عندما يلاحظ العملاء حالات فشل في الطلبات أو وقت استجابة مرتفع أو أخطاء 429، عليهم الحدّ من معدّل تدفق البيانات الصادرة طوعًا لتجنُّب تفاقم الازدحام.
خوارزمية الرقود الأسي الثنائي: عند إعادة محاولة تصحيح الأخطاء، أضِف حالات تأخير تزداد بشكل كبير. على سبيل المثال: ثانية واحدة، ثانيتان، 4 ثوانٍ، 8 ثوانٍ، 16 ثانية، 32 ثانية، وهكذا.
التأخير العشوائي: تجنُّب إعادة محاولة إرسال الطلبات في فترات زمنية دقيقة باستخدام التذبذب، يمكنك تغيير فترات تأخير إعادة المحاولة من خلال عملية عشوائية لتوزيعها بشكل موحد بمرور الوقت (على سبيل المثال: 0.9 ثانية، 2.3 ثانية، 4.1 ثانية، 8.5 ثانية، 17.9 ثانية، 34.7 ثانية).
تضخيم إعادة المحاولة: عند إعادة محاولة إرسال الطلبات التي تعذّر تنفيذها بدون استخدام خوارزمية الرقود الأسي الثنائي أو التذبذب، غالبًا ما تتراكم هذه الطلبات وتزيد من عبء عدد الزيارات الحالي، ما قد يؤدي إلى "تضخيم" مشاكل ازدحام الزيارات وتفاقمها.
المشكلة: الارتفاعات المفاجئة في عدد الزيارات
تعالج خدمة FCM ملايين الطلبات في الثانية (RPS). أكبر مساهم في الازدحام المنهجي ومشاكل زمن الوصول والانقطاعات هو الارتفاعات المفاجئة في عدد الزيارات.
ما هي الزيارات المتقطّعة؟
هناك عدة أنواع مختلفة من الارتفاعات المفاجئة في عدد الزيارات.
الارتفاعات المفاجئة في بداية كل ساعة: تتلقّى خدمة FCM أكثر من ضعف عدد الزيارات خلال أول 30 ثانية إلى دقيقتين من كل ساعة. يتم أيضًا رصد ارتفاعات مماثلة، وإن كانت أقل، عند علامات نصف الساعة وربع الساعة (أمثلة: 00:15، 00:30، 00:45)
تضخيم إعادة المحاولة: يمكن أن تؤدي إعادة محاولة الطلبات التي تعذّر تنفيذها أو التي انتهت مهلتها بدون التراجع الأسي إلى تراكم موجات متكررة من الزيارات فوق ذروة الزيارات الحالية.
التغييرات المفاجئة في أنماط الزيارات: يمكن أن يؤدي توجيه زيارات جديدة إلى FCM أو نقل الزيارات إلى FCM في مناطق مختلفة بدون عوامل تسهيل، مثل الزيادة التدريجية، إلى حدوث ارتفاعات مفاجئة.
استخدام رموز الحصة المميزة في البداية: إنّ استنفاد جميع رموز الحصة المميزة في بداية نوافذ الحصة بدلاً من توزيع الطلبات بالتساوي على نوافذ الحصة سيؤدي إلى حدوث تذبذبات في التشغيل والإيقاف يصعب موازنة الحمل فيها وتكون مكلفة.
الأحداث الخاصة: ارتفاعات في عدد الزيارات خلال الأعياد (ليلة رأس السنة) أو الأحداث الرياضية (كأس العالم FIFA)
معالجة الارتفاعات المفاجئة في عدد الزيارات من خلال "تسطيح المنحنى"
يصف هذا القسم استراتيجيات لتخفيف الارتفاعات المفاجئة في عدد الزيارات حيثما أمكن، وهي استراتيجيات "لتسوية المنحنى".
استخدام FCM في حالات الاستخدام المناسبة فقط
هناك بعض حالات الاستخدام التي لا يكون فيها استخدام FCM لإرسال إشعار ضروريًا أو مناسبًا.
على سبيل المثال، بالنسبة إلى إشعارات أحداث التقويم، يمكنك جدولة مهمة محلية في تطبيقك لعرض إشعار في الأوقات المناسبة بدلاً من إرساله من خادم التطبيق. يمكنك حصر رسائل FCM على عمليات مزامنة التقويم.
تجنُّب الارتفاعات المفاجئة
من الأنماط المضادة لتوسيع النطاق إرسال إشعارات FCM بأسرع ما تسمح به الأنظمة، بدلاً من تطبيق تقييد من جهة الخادم. ننصحك باتّباع الخطوات التالية:
- هل يحتاج جميع عملائك إلى تلقّي الإشعار نفسه خلال دقيقة واحدة؟ على سبيل المثال، هل لا تزال فترة التسليم التي تبلغ 5 دقائق تلبي احتياجات عملك؟
- هل يمكن تقسيم عملائك استنادًا إلى الأولوية لتسهيل التعامل مع الارتفاعات المفاجئة؟
- هل يمكن جدولة الإشعارات مسبقًا؟
كلما أمكن: تجنَّب الاستراتيجيات التي تؤدي إلى استنفاد حصة الإرسال في FCM على الفور، ثم تكرار النمط نفسه بمجرد إعادة ملء حزمة الرموز المميزة. يؤدي نمط الوصول هذا إلى حدوث مشاكل في موازنة الحمل في FCM والأنظمة التي تعتمد عليها. زيادة عدد الزيارات تدريجيًا قدر الإمكان At minimum, ramp from 0 to the max RPS across a 60 second time-window. يُفضَّل استخدام فترات زمنية أطول لزيادة معدّل الإيرادات لكلّ جلسة.
تجنُّب حركة المرور الكثيفة في بداية كل ساعة
حيثما أمكن: تجنَّب إرسال الرسائل خلال دقيقتين من كل من علامات الدقائق :00 و:15 و:30 و :45.
تنفيذ الحدّ من عدد الطلبات من جهة الخادم
تنفيذ عملية تقييد من جهة الخادم لمراقبة تدفق الزيارات إلى FCM وإدارتها
التعامل مع عمليات إعادة المحاولة
مع أنّ FCM تسعى إلى أن تكون متاحة بشكل كبير، ستنتهي مهلة بعض الطلبات أو يتعذّر إكمالها في بعض الأحيان. تختلف الأسباب، ولكن أفضل الممارسات التالية تحسّن سلوك إعادة المحاولة لتسليم الرسائل في أقرب وقت ممكن مع تقليل التأثير في ازدحام حركة البيانات.
عمليات الاستبعاد المؤقت للقناة
يجب ضبط مهلة لا تقل عن 10 ثوانٍ لطلبات الإرسال قبل إعادة المحاولة. تستخدم معظم استدعاءات الإجراءات عن بُعد الداخلية في FCM مهلة تبلغ 10 ثوانٍ.
الأخطاء
- بالنسبة إلى الأخطاء 400 و401 و403 و404: يجب إلغاء العملية وعدم إعادة المحاولة.
- بالنسبة إلى أخطاء 429: أعِد المحاولة بعد الانتظار للمدة المحدّدة في عنوان retry-after. إذا لم يتم ضبط عنوان retry-after، يتم ضبطه تلقائيًا على 60 ثانية.
- بالنسبة إلى الأخطاء 500: أعِد المحاولة باستخدام خوارزمية الرقود الأسي الثنائي.
الرقود الأسي الثنائي
لتجنُّب تضخيم عدد المحاولات، يمكنك تنفيذ خوارزمية الرقود الأسي الثنائي مع التذبذب لإعادة محاولة إرسال الطلبات. على سبيل المثال، تستخدم حزمة تطوير البرامج (SDK) لمشرف Firebase استراتيجية الانتظار الأسي.
في ما يلي بعض الإعدادات الإضافية المقترَحة:
- الحد الأدنى للفاصل الزمني: لا تُعِد محاولة إرسال طلب تعذّر إرساله باستخدام FCM على الفور. انتظِر لمدة 10 ثوانٍ على الأقل قبل إعادة محاولة إرسال طلب تعذّر إكماله.
- الحد الأقصى للفاصل الزمني: يمكنك ضبط حد أقصى للفاصل الزمني لإسقاط الطلبات التي لم تعد مناسبة، بدلاً من إعادة المحاولة إلى أجل غير مسمى.
إذا تمت إعادة محاولة إرسال الطلب باستمرار باستخدام خوارزمية الرقود الأسي الثنائي وكان لا يزال يتعذّر إرساله بعد 60 دقيقة، يعني ذلك أنّه تم تصنيفه بشكل خاطئ كخطأ يمكن إعادة المحاولة فيه، أو أنّ خدمة مراسلة Firebase السحابية تواجه انقطاعًا قد تؤدي فيه عمليات إعادة المحاولة إلى تفاقم الوضع عن غير قصد.
إنشاء خطط الطرح والتراجع وإجراء تغييرات تدريجية
عند إجراء تغييرات كبيرة على عدد الزيارات، مثل زيادة عدد الزيارات إلى FCM أو نقل عدد الزيارات عبر المناطق أو الشبكات، فإنّ تصميم خطة طرح/تراجع وتنفيذ تغييرات تدريجية سيحمي المستخدمين والخدمة وFCM.
- تساعد خطة الطرح في مواءمة توقعات الأطراف المعنية. في بعض الحالات (الموضّحة أدناه)، قد تحتاج إلى مشاركة خطة الطرح مسبقًا مع فريق FCM لتجنُّب المفاجآت.
- تتيح لك خطة التراجع الاستعداد لحالات الطوارئ وتجهيز آليات للتعافي بسرعة وأمان من الأعطال غير المتوقعة.
- يتضمن إجراء التغييرات التدريجية جانبَين:
- عمليات الطرح "التدريجية": يجب أن تكون الخطوات %1 -> %5 -> %10 -> %25 -> %50 -> %75 -> %100 أو أقل. مراقبة (مراقبة سلوك النظام تحت الضغط) كل خطوة لمدة تتراوح بين يوم واحد وأسبوع واحد يتيح لك ذلك رصد المشاكل المحتملة قبل "الخطوة التالية"
- زيادة عدد الزيارات تدريجيًا: عند اتّخاذ كل "خطوة" لزيادة عدد الزيارات، يجب توزيع الزيارات بسلاسة على مدار ساعة على الأقل. يسمح ذلك للبنية الأساسية لموازنة الحمل في FCM بتوسيع نطاق عدد الزيارات الجديد بشكل مناسب مع تقليل احتمالية حدوث نقاط ازدحام.
في ما يلي سيناريو افتراضي لنقل 500,000 طلب في الثانية على مستوى العالم من واجهة برمجة التطبيقات HTTP القديمة في FCM إلى الإصدار 1 من واجهة برمجة التطبيقات HTTP في FCM:
| الأسبوع | Step | استراتيجية الزيادة التدريجية |
|---|---|---|
| 0 | توفير الميزة لـ %1 من المستخدمين | يمكنك زيادة عدد الطلبات تدريجيًا من 0 إلى 5,000 طلب في الثانية إلى الإصدار 1 من واجهة برمجة التطبيقات HTTP في 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 | توفير الميزة بالكامل | زيادة من 375,000 إلى 500,000 طلب في الثانية على مدار 6 ساعات |
خطة افتراضية للعودة إلى الإصدار السابق:
- إذا زاد وقت الاستجابة في المئوية 95 إلى أكثر من 500 ملي ثانية أو إذا تجاوزت نسبة الخطأ %1 لأكثر من ساعة في أي خطوة، استخدِم الإعدادات الديناميكية للعودة إلى الخطوة السابقة على الفور.
- مواصلة عمليات العودة إلى الخطوات السابقة إلى أن يعود وقت الاستجابة ونسبة الخطأ إلى المستويات الاسمية
متى يجب التواصل مع فريق FCM؟
يُرجى التواصل مع فريق FCM من خلال دعم Firebase في حال انطباق أيّ مما يلي:
- لم تعُد الحصص التلقائية تلبّي احتياجاتك
- إذا كنت بصدد تغيير أنماط الإرسال خلال فترة 3 أشهر على نطاق 100,000 طلب في الثانية على مستوى العالم أو 30,000 طلب في الثانية على مستوى القارة