سواء كنت بصدد تطوير تطبيق جديد أو تدير حاليًا خدمة تستقبل عددًا كبيرًا من الزيارات، يمكنك الاستفادة من الأفكار والاقتراحات الواردة في هذا الدليل حول كيفية التوسّع بسلاسة باستخدام FCM. يمكن أن تساعدك هذه المفاهيم والممارسات في تجنُّب التأثيرات السلبية عند الحاجة إلى إرسال أعداد كبيرة من الرسائل.
المصطلحات والمفاهيم الرئيسية
طلب الرسالة: هو طلب رسالة FCM، ويُستخدم بالتبادل مع "الطلب" أو "الرسالة" أو "طلب البحث".
الطلبات في الثانية: مقياس لوصف معدّل الطلبات الواردة إلى FCM، ويُستخدم بالتبادل مع "طلبات البحث في الثانية".
الرموز المميزة للحصة، وحاويات الرموز المميزة، وعمليات إعادة التعبئة: عند إرسال رسائل باستخدام الإصدار 1 من واجهة برمجة تطبيقات HTTP لمراسلة Firebase السحابية، يستهلك كل طلب رمزًا مميزًا للحصة مخصّصًا خلال فترة زمنية محدّدة. تتم إعادة تعبئة هذه النافذة، التي تُعرف باسم "حزمة الرموز المميزة"، بالكامل في نهاية الفترة الزمنية المحددة. على سبيل المثال، تخصص واجهة برمجة التطبيقات 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 لحالات الاستخدام المناسبة فقط
هناك بعض حالات الاستخدام التي لا يكون فيها استخدام FCM لإرسال إشعار ضروريًا أو مناسبًا.
على سبيل المثال، بالنسبة إلى إشعارات أحداث التقويم، يمكنك جدولة مهمة محلية في تطبيقك لعرض إشعار في الأوقات المناسبة بدلاً من إرساله من خادم تطبيقك. قصر رسائل FCM على عمليات مزامنة التقويم.
تجنُّب الارتفاعات المفاجئة
أحد الأنماط المضادة لتوسيع النطاق هو إرسال إشعارات FCM بأسرع ما تسمح به الأنظمة، بدلاً من تطبيق الحدّ الأقصى لعدد الطلبات من جهة الخادم. يُرجى مراعاة ما يلي:
- هل يجب أن يتلقّى جميع عملائك الإشعار نفسه خلال فترة دقيقة واحدة؟ هل ستظلّ فترة التسليم التي تبلغ 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 دقيقة، يعني ذلك أنّه تم تصنيفه بشكل خاطئ كخطأ يمكن إعادة المحاولة، أو أنّ خدمة 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 طلب في الثانية إلى الإصدار 1 من واجهة برمجة تطبيقات HTTP لمراسلة Firebase السحابية على مدار ساعة |
| 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 طلب في الثانية على مستوى القارة