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