سواء كنت بصدد تطوير تطبيق جديد أو تدير حاليًا خدمة تستقبل عددًا كبيرًا من الزيارات، يمكنك الاستفادة من الأفكار والاقتراحات الواردة في هذا الدليل حول كيفية التوسّع بسلاسة باستخدام FCM. يمكن أن تساعدك هذه المفاهيم والممارسات في تجنُّب التأثيرات السلبية عندما تحتاج إلى إرسال كميات كبيرة من الرسائل.
المصطلحات والمفاهيم الرئيسية
طلب رسالة: هو طلب رسالة عبر خدمة "مراسلة Firebase السحابية"، ويُستخدم بالتبادل مع "طلب" أو "رسالة" أو "طلب بحث".
الطلبات في الثانية (RPS): مقياس لوصف معدّل الطلبات الواردة إلى FCM، ويُستخدم بشكل تبادلي مع الطلبات في الثانية (QPS).
رموز الحصة المميّزة وحِزم الرموز المميّزة وعمليات إعادة التعبئة: عند إرسال رسائل إلى الإصدار 1 من واجهة برمجة تطبيقات HTTP لمراسلة Firebase السحابية، يستهلك كل طلب رمز حصة مميّز مخصّصًا في فترة زمنية معيّنة. تتم إعادة تعبئة هذه النافذة، التي تُعرف باسم "مخزن الرموز المميزة"، بالكامل في نهاية الفترة الزمنية. على سبيل المثال: تمنح واجهة برمجة التطبيقات HTTP v1 API 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 في مناطق مختلفة بدون عوامل تسهيل، مثل الزيادة التدريجية، إلى حدوث ارتفاعات مفاجئة.
الاستخدام المسبق لرموز الحصة: سيؤدي استنفاد جميع رموز الحصة في بداية فترات الحصة بدلاً من توزيع الطلبات بالتساوي على فترات الحصة إلى حدوث تذبذبات متقطّعة يصعب موازنة الحمل فيها وتكون مكلفة.
الأحداث الخاصة: ارتفاعات في عدد الزيارات خلال الأعياد (ليلة رأس السنة) أو الأحداث الرياضية (كأس العالم 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 دقيقة، يعني ذلك إما أنّه تم تصنيفه بشكل خاطئ على أنّه خطأ يمكن إعادة المحاولة فيه، أو أنّ خدمة FCM تواجه انقطاعًا قد يؤدي إلى تفاقم المشكلة عن غير قصد.
إنشاء خطط طرح وتراجع، وإجراء تغييرات تدريجية
عند إجراء تغييرات كبيرة على عدد الزيارات، مثل زيادة عدد الزيارات إلى 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 لمراسلة 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 لأكثر من ساعة في أي خطوة، استخدِم الإعدادات الديناميكية للعودة إلى الخطوة السابقة على الفور.
- واصِل التراجع إلى الخطوات السابقة حتى يعود وقت الاستجابة ونسبة الخطأ إلى المستويات الاسمية.
متى يجب التواصل مع فريق FCM؟
يُرجى التواصل مع فريق FCM من خلال دعم Firebase في حال انطباق أيّ مما يلي:
- لم تعُد الحصص التلقائية تلبي احتياجاتك
- إذا كنت بصدد تغيير أنماط الإرسال خلال فترة 3 أشهر على نطاق 100,000 طلب في الثانية على مستوى العالم أو 30,000 طلب في الثانية على مستوى القارة