سواء كنت بصدد تطوير تطبيق جديد أو تدير حاليًا خدمة تستقبل عددًا كبيرًا من الزيارات، يمكنك الاستفادة من الأفكار والاقتراحات الواردة في هذا الدليل حول كيفية التوسّع بسلاسة باستخدام FCM. يمكن أن تساعدك هذه المفاهيم والممارسات في تجنُّب التأثيرات السلبية عند الحاجة إلى إرسال أعداد كبيرة من الرسائل.
المصطلحات والمفاهيم الرئيسية
طلب الرسالة: هو طلب رسالة عبر السحابة الإلكترونية من Firebase، ويُستخدم بالتبادل مع "الطلب" أو "الرسالة" أو "طلب البحث".
الطلبات في الثانية (RPS): مقياس لوصف معدّل الطلبات الواردة إلى FCM، ويُستخدم بالتبادل مع طلبات البحث في الثانية (QPS).
الرموز المميزة للحصة، وحاويات الرموز المميزة، وعمليات إعادة التعبئة: عند إرسال رسائل إلى واجهة برمجة التطبيقات FCM HTTP v1، يستهلك كل طلب رمزًا مميزًا للحصة مخصّصًا خلال فترة زمنية محدّدة. تتم إعادة تعبئة هذه النافذة، التي تُعرف باسم "حاوية الرموز المميزة"، بالكامل في نهاية النافذة الزمنية. على سبيل المثال، تتيح واجهة برمجة التطبيقات HTTP v1 600 ألف رمز مميّز للحصة لكل حزمة رموز مميّزة مدتها دقيقة واحدة، ويتم إعادة تعبئتها بالكامل في نهاية كل فترة زمنية مدتها دقيقة واحدة.
تقييد البيانات من جهة الخادم: عندما يتجاوز حجم الزيارات سعة خدمة FCM، يتم رفض الطلبات التي تتجاوز سعة العرض للحدّ من معدّل تدفّق البيانات الواردة. قد يتم عرض استجابات الخطأ 429 مع عناوين retry-after للإشارة إلى أنّه عليك الانتظار لفترة زمنية محدّدة قبل إعادة محاولة الطلب.
الحدّ من عدد الطلبات من جهة العميل: عندما يلاحظ العملاء حدوث أخطاء في الطلبات أو زيادة في وقت الاستجابة أو أخطاء 429، عليهم الحدّ من عدد الطلبات الصادرة بشكل طوعي لتجنُّب تفاقم الازدحام.
الرقود الأسي الثنائي: عند إعادة محاولة تصحيح الأخطاء، أضِف حالات تأخير زمنية متزايدة بشكل أسي. على سبيل المثال: 1s و2s و4s و8s و16s و32s وما إلى ذلك.
التذبذب: تجنُّب إعادة محاولة الطلبات على فترات زمنية متطابقة باستخدام التشوّش، يمكنك تغيير فترات التأخير بين المحاولات من خلال عملية عشوائية لتوزيعها بشكل منتظم بمرور الوقت (على سبيل المثال: 0.9 ثانية، 2.3 ثانية، 4.1 ثانية، 8.5 ثانية، 17.9 ثانية، 34.7 ثانية).
تضخيم عمليات إعادة المحاولة: عندما تتم إعادة محاولة إرسال الطلبات التي تعذّر تنفيذها بدون استخدام خوارزمية الرقود الأسي الثنائي أو التشوّش، غالبًا ما تتراكم وتزيد من حمل الزيارات المستمر، ما قد يؤدي إلى "تضخيم" مشاكل الازدحام المروري وتفاقمها.
المشكلة: ارتفاع عدد الزيارات
تعالج خدمة FCM ملايين الطلبات في الثانية (RPS). إنّ أبرز العوامل التي تؤدي إلى الازدحام المنهجي ومشاكل وقت الاستجابة والانقطاعات هي الارتفاعات المفاجئة في عدد الزيارات.
ما هي الزيارات المفاجئة؟
هناك عدة أنواع مختلفة من الارتفاعات المفاجئة في عدد الزيارات.
الارتفاعات المفاجئة في بداية كل ساعة: يتلقّى FCM أكثر من ضعف عدد الزيارات خلال أول 30 ثانية إلى دقيقتين من كل ساعة. يُلاحظ أيضًا حدوث ارتفاعات مشابهة، وإن كانت أقل، عند علامات نصف الساعة وربع الساعة (أمثلة: 00:15 و00:30 و00:45).
تضخيم إعادة المحاولة: يمكن أن تتراكم عمليات إعادة محاولة الطلبات التي تعذّر تنفيذها أو انتهت مهلتها بدون التراجع الأسي لتشكّل موجات متكرّرة من الزيارات فوق قمم الزيارات الحالية.
التغييرات المفاجئة في أنماط الزيارات: يمكن أن يؤدي توجيه الزيارات الجديدة إلى FCM أو نقل الزيارات إلى FCM في جميع المناطق بدون عوامل تسوية، مثل الزيادة التدريجية، إلى حدوث ارتفاعات مفاجئة.
الاستخدام المسبق لرموز الحصة: سيؤدي استنفاد جميع رموز الحصة في بداية فترات الحصة بدلاً من توزيع الطلبات بالتساوي على فترات الحصة إلى حدوث تذبذبات متقطّعة يصعب موازنة الحمل فيها وتكون مكلفة.
الأحداث الخاصة: ارتفاع عدد الزيارات خلال العطلات (ليلة رأس السنة) أو الأحداث الرياضية (كأس العالم لكرة القدم)
معالجة الارتفاعات المفاجئة في عدد الزيارات من خلال "تسطيح المنحنى"
يوضّح هذا القسم استراتيجيات للحدّ من الارتفاعات المفاجئة في عدد الزيارات حيثما أمكن ذلك، أي استراتيجيات "تسطيح المنحنى".
استخدام السمة FCM لحالات الاستخدام المناسبة فقط
هناك بعض حالات الاستخدام التي لا يكون فيها استخدام ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" لإرسال إشعار ضروريًا أو مناسبًا.
على سبيل المثال، بالنسبة إلى إشعارات أحداث التقويم، يمكنك جدولة مهمة محلية في تطبيقك لعرض إشعار في الأوقات المناسبة بدلاً من إرساله من خادم تطبيقك. قصر رسائل FCM على عمليات مزامنة التقويم.
تجنُّب الارتفاعات المفاجئة
أحد الأنماط المضادة لتوسيع النطاق هو إرسال إشعارات FCM بأسرع ما تسمح به الأنظمة، بدلاً من تطبيق الحدّ الأقصى لعدد الطلبات من جهة الخادم. يُرجى مراعاة ما يلي:
- هل يحتاج جميع عملائك إلى تلقّي الإشعار نفسه خلال دقيقة واحدة؟ هل ستظلّ فترة التسليم التي تبلغ 5 دقائق، مثلاً، تلبي احتياجات نشاطك التجاري؟
- هل يمكن تقسيم عملائك استنادًا إلى الأولوية لتجنُّب الارتفاعات المفاجئة؟
- هل يمكن جدولة الإشعارات مسبقًا؟
حيثما أمكن: تجنَّب الاستراتيجيات التي تؤدي إلى استنفاد حصة الإرسال في "المراسلة عبر السحابة الإلكترونية من Firebase" على الفور، ثم تكرار النمط بمجرد إعادة تعبئة سعة الرمز المميز. يؤدي نمط الوصول هذا إلى حدوث مشاكل في موازنة التحميل في 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 دقيقة، يعني ذلك إما أنّه تم تصنيفه بشكل خاطئ على أنّه خطأ يمكن إعادة المحاولة فيه، أو أنّ خدمة FCM تواجه انقطاعًا قد يؤدي إلى تفاقم المشكلة عن غير قصد.
إنشاء خطط طرح وتراجع، وإجراء تغييرات تدريجية
عند إجراء تغييرات واسعة النطاق على عدد الزيارات، مثل زيادة عدد الزيارات إلى FCM أو نقل عدد الزيارات بين المناطق أو الشبكات، سيؤدي تصميم خطة طرح/إرجاع وتنفيذ تغييرات تدريجية إلى حماية المستخدمين والخدمة وFCM.
- تساعد خطة الطرح في توحيد التوقعات لدى الأطراف المعنية. في حالات معيّنة (سيتم توضيحها أدناه)، قد تحتاج إلى مشاركة خطة الطرح مع فريق FCM مسبقًا لتجنُّب أي مفاجآت.
- تتيح لك خطة التراجع عن التغييرات إمكانية الاستعداد للطوارئ وتجهيز آليات لاسترداد البيانات بسرعة وأمان في حال حدوث أعطال غير متوقّعة.
- يتضمّن إجراء تغييرات تدريجية جانبَين:
- عمليات الزيادة التدريجية: يجب أن تكون الخطوات %1 -> %5 -> %10 -> %25 -> %50 -> %75 -> %100 أو أكثر دقة. الاختبار المطوّل (مراقبة سلوك النظام تحت الحمل) لكل خطوة لمدة تتراوح بين يوم واحد وأسبوع واحد يتيح لك ذلك رصد المشاكل المحتملة قبل "الخطوة التالية".
- زيادة عدد الزيارات تدريجيًا: عند اتّخاذ كل "خطوة" لزيادة عدد الزيارات، يجب أن يتم ذلك بسلاسة على مدار ساعة واحدة على الأقل. يسمح ذلك للبنية الأساسية لموازنة التحميل في خدمة FCM بتوسيع نطاق عدد الزيارات الجديدة بشكل مناسب مع تقليل احتمالية حدوث نقاط اتصال وازدحام.
في ما يلي سيناريو افتراضي لنقل 500,000 طلب في الثانية على مستوى العالم من واجهة برمجة التطبيقات القديمة المستندة إلى HTTP في "المراسلة عبر السحابة الإلكترونية من Firebase" إلى الإصدار 1 من واجهة برمجة التطبيقات المستندة إلى HTTP في "المراسلة عبر السحابة الإلكترونية من Firebase":
| أسبوع | Step | استراتيجية التوفير التدريجي |
|---|---|---|
| 0 | توفير الميزة بنسبة% 1 | يمكنك زيادة عدد الطلبات بسلاسة من 0 إلى 5,000 طلب في الثانية إلى FCM HTTP v1 على مدار ساعة. |
| 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 في حال توفّر أيّ مما يلي:
- لم تعُد الحصص التلقائية مناسبة لحالة الاستخدام
- تغيير أنماط الإرسال خلال فترة 3 أشهر بمعدّل 100,000 طلب في الثانية على مستوى العالم أو 30,000 طلب في الثانية على مستوى القارة