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