سواء كان تطبيقك مبتدئًا أو تستخدم خدمة تستقبل عدد زيارات كبيرًا، يمكنك الاستفادة من الإحصاءات والاقتراحات المقدّمة في هذا الدليل حول كيفية التوسّع بسلاسة باستخدام ميزة "المراسلة عبر السحابة الإلكترونية من Firebase". يمكن أن تساعدك هذه المفاهيم والممارسات على تجنب التأثيرات السلبية عندما تحتاج إلى إرسال أعداد كبيرة من الرسائل.
المصطلحات والمفاهيم الرئيسية
طلب الرسالة: طلب رسالة من "المراسلة عبر السحابة الإلكترونية من Firebase"، ويُستخدَم بالتبادل مع "الطلب" أو "الرسالة" أو "طلب البحث".
الطلبات في الثانية (RPS): مقياس لوصف معدّل الطلبات الواردة إلى خدمة "المراسلة عبر السحابة الإلكترونية من Firebase"، ويتم استخدامه بشكل تبادلي مع طلبات البحث في الثانية (QPS).
الرموز المميّزة للحصص وحِزم الرموز المميّزة وعمليات إعادة التعبئة: عند إرسال الرسائل باستخدام واجهة برمجة التطبيقات FCM HTTP v1 API، يستهلك كل طلب رمزًا مميّزًا للحصة مخصّصًا له في مهلة زمنية معيّنة. تُعرف هذه النافذة باسم "حزمة الرموز المميّزة"، ويتم إعادة ملؤها بالكامل في نهاية الإطار الزمني. على سبيل المثال: تُخصّص واجهة برمجة التطبيقات 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).
تضخيم عمليات إعادة المحاولة: عند إعادة محاولة إرسال الطلبات التي تعذّر تنفيذها بدون استخدام أسلوب /jitter) (الرقود الأسي الثنائي، غالبًا ما تتراكم هذه الطلبات وتزيد من عدد الزيارات الجارية، ما قد يؤدي إلى "تضخيم" مشاكل ازدحام الزيارات وتفاقمها.
المشكلة: الارتفاعات المفاجئة في عدد الزيارات
تعالج خدمة "إرسال الرسائل إلى الأجهزة الجوّالة من Google" ملايين الطلبات في الثانية (RPS). إنّ الارتفاعات المفاجئة في عدد الزيارات هي السبب الرئيسي في الازدحام على مستوى النظام ومشاكل وقت الاستجابة وانقطاعات الخدمة.
ما هي حركة المرور المرتفعة؟
هناك عدّة أنواع مختلفة من الارتفاعات المفاجئة في حركة الزيارات.
الارتفاعات في عدد الطلبات في الساعة: تتلقّى خدمة "إرسال إشعارات Google" أكثر من ضعف عدد الطلبات خلال أوّل 30 ثانية إلى دقيقتين من كل ساعة. مماثلة، وإن كانت أقل، تتم ملاحظة الارتفاعات أيضًا عند علامات نصف الساعة وربع ساعة (أمثلة: 00:15، 00:30، 00:45)
تضخيم عمليات إعادة المحاولة: يمكن أن تؤدي إعادة محاولة الطلبات التي تعذّر إكمالها أو انتهت مهلة إرسالها بدون استخدام الوقت المتزايد للانتظار إلى تراكم موجات متكرّرة من الزيارات فوق قمم الزيارات الحالية.
التغييرات المفاجئة في نمط الزيارات: يمكن أن يؤدي توجيه الزيارات الجديدة إلى "نظام إدارة الموافقة" أو نقل الزيارات إلى "نظام إدارة الموافقة" في جميع المناطق بدون عوامل تسوية مثل الزيادة التدريجية إلى التسبب في حدوث طفرات.
استخدام الرموز المميزة للحصة في وقت مبكر: يؤدي استخدام كل الرموز المميزة للحصة في بداية فترات الحصة بدلاً من توزيع الطلبات بالتساوي على فترات الحصة إلى إنشاء تقلّبات متكررة يصعب تسويتها من خلال التوازن في الحمولة.
الأحداث الخاصة: الارتفاعات المفاجئة في عدد الزيارات خلال العطلات (عشية رأس السنة الجديدة) أو الأحداث الرياضية (كأس العالم لكرة القدم).
حلّ المشاكل المتعلّقة بالزيارات المرتفعة من خلال "تسطيح المنحنى"
يصف هذا القسم إستراتيجيات لتخفيف حدة الارتفاع المفاجئ في حركة الزيارات حيثما أمكن ذلك - استراتيجيات "تسوية المنحنى".
استخدِم FCM مع حالات الاستخدام المناسبة فقط.
هناك بعض حالات الاستخدام التي لا يكون فيها استخدام Firebase Cloud Messaging لإرسال إشعار ضروريًا أو مناسبًا.
على سبيل المثال، بالنسبة إلى إشعارات أحداث التقويم، يمكنك جدولة مهمة محلية في تطبيقك لعرض إشعار في الأوقات المناسبة بدلاً من إرساله من خادم التطبيق. يمكنك قصر رسائل خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" على عمليات مزامنة التقويم.
تجنُّب الارتفاعات
أحد أنماط التعدين المتدرجة هي إرسال إشعارات "المراسلة عبر السحابة الإلكترونية من Firebase" بأسرع ما تسمح به الأنظمة، بدلاً من تطبيق التقييد من جهة الخادم. يُرجى مراعاة ما يلي:
- هل يجب أن يتلقّى جميع عملائك الإشعار نفسه خلال فترة زمنية تبلغ دقيقة واحدة؟ هل ستظل فترة التسليم التي تبلغ 5 دقائق، على سبيل المثال، تلبي احتياجات نشاطك التجاري؟
- هل يمكن تقسيم عملائك استنادًا إلى الأولوية للتخفيف من الارتفاعات المفاجئة؟
- هل يمكن جدولة إشعاراتك مسبقًا؟
كلما أمكن: تجنَّب الاستراتيجيات التي تؤدي إلى استنفاد حصة إرسال "المراسلة عبر السحابة الإلكترونية من Firebase" على الفور، ثم تكرار النمط فور إعادة تعبئة حزمة الرموز المميّزة. يتسبب نمط الوصول هذا في مشاكل توازن التحميل لخدمة "إشعارات Google من خادم Firebase" والأنظمة التي تعتمد عليها. ارفع عدد الزيارات تدريجيًا قدر الإمكان. يجب زيادة عدد الطلبات في الثانية من 0 إلى الحد الأقصى لها خلال فترة زمنية تبلغ 60 ثانية على الأقل. يُفضَّل استخدام فترات زمنية أطول لزيادة معدل طلبات البحث في الثانية.
تجنّب حركة المرور على مدار الساعة
حيثما أمكن: تجنَّب إرسال الرسائل خلال فترة دقيقتَين من كل من علامات :00 و:15 و:30 و :45 دقيقة.
تنفيذ عملية التحكّم في السرعة من جهة الخادم
تنفيذ التقييد من جهة الخادم لمراقبة تدفق الزيارات إلى "المراسلة عبر السحابة الإلكترونية من Firebase" وإدارته.
التعامل مع عمليات إعادة المحاولة
على الرغم من أنّ منصة 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 أو أكثر دقة. "الحمل الزائد" (مراقبة سلوك النظام تحت الحمل) لكل خطوة لمدة تتراوح بين يوم واحد وأسبوع واحد يتيح لك ذلك رصد المشاكل المحتمَلة قبل "التحسين" التالي.
- زيادة تدريجية في حركة المرور: عند اتخاذ كل "خطوة" لزيادة حركة المرور، عليك تسهيل حركة المرور على مدى ساعة واحدة على الأقل. ويسمح ذلك للبنية الأساسية لميزة "موازنة الحمولة" في منصة "إرسال الرسائل إلى Firebase" بتوسيع نطاق زياراتك الجديدة بشكلٍ مناسب مع الحدّ من احتمال حدوث نقاط اتصال وازدحام.
في ما يلي سيناريو افتراضي لنقل 500,000 طلب في الثانية على مستوى العالم من واجهة برمجة التطبيقات القديمة لـ HTTP في "خدمة المراسلة عبر السحابة الإلكترونية من Firebase" إلى الإصدار 1 من واجهة برمجة التطبيقات لـ HTTP في "خدمة المراسلة عبر السحابة الإلكترونية من Firebase":
| الأسبوع | Step | استراتيجية التوسّع التدريجي |
|---|---|---|
| 0 | زيادة بنسبة %1 | الزيادة السلسة من 0 إلى 5,000 لقطة في الثانية إلى الإصدار 1 من خدمة "المراسلة عبر السحابة الإلكترونية من 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 | زيادة السرعة إلى أقصى حد | زيادة معدّل عمليات تسجيل البيانات من 375,000 إلى 500,000 عملية في الثانية على مدار 6 ساعات |
خطة افتراضية للرجوع إلى الإصدار السابق:
- في حال زيادة وقت الاستجابة بنسبة 95 في المئة إلى أكثر من 500 ملي ثانية أو إذا تجاوزت نسبة الخطأ% 1 لأكثر من ساعة في أيّ خطوة، يمكنك استخدام الإعداد الديناميكي للعودة إلى الخطوة السابقة على الفور.
- مواصلة العودة إلى الخطوات السابقة إلى أن تعود نسبة وقت الاستجابة والخطأ إلى المستويات الاسمية
حالات التواصل مع فريق "المراسلة عبر السحابة الإلكترونية من Firebase"
يُرجى التواصل مع فريق خدمة عملاء Firebase من خلال فريق دعم Firebase في حال انطباق أيّ من الشروط التالية:
- لم تعُد الحصص التلقائية تستوفي حالة الاستخدام
- إذا كنت تغيّر أنماط الإرسال خلال فترة 3 أشهر على مستوى 100,000 طلب في الثانية على مستوى العالم أو 30,000 طلب في الثانية على مستوى قارة