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