سواء كنت تقوم بتطوير تطبيق ناشئ أو تقوم بالفعل بتشغيل خدمة ذات حركة مرور عالية، يمكنك الاستفادة من رؤى هذا الدليل وتوصياته حول كيفية التوسع بسلاسة باستخدام FCM. يمكن أن تساعدك هذه المفاهيم والممارسات على تجنب التأثيرات السلبية عندما تحتاج إلى إرسال كميات كبيرة من الرسائل.
المصطلحات والمفاهيم الأساسية
طلب رسالة : طلب رسالة FCM؛ تُستخدم بالتبادل مع "طلب" أو "رسالة" أو "استعلام".
الطلبات في الثانية (RPS) : مقياس لوصف معدل الطلبات الواردة إلى FCM؛ يتم استخدامه بالتبادل مع الاستعلامات في الثانية (QPS).
رموز الحصص ومجموعات الرموز المميزة وعمليات إعادة التعبئة : عند إرسال رسائل مقابل FCM HTTP v1 API، يستهلك كل طلب رمز الحصة المخصص في نافذة زمنية معينة. هذه النافذة، التي تسمى " Token Bucket "، تتم إعادة تعبئتها بالكامل في نهاية النافذة الزمنية. على سبيل المثال: تقوم واجهة برمجة تطبيقات 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 إلى الحد الأقصى لعدد RPS عبر نافذة زمنية مدتها 60 ثانية. تفضل النوافذ الأطول للحصول على RPS أعلى.
تجنب حركة المرور "على مدار الساعة".
حيثما أمكن : تجنب إرسال الرسائل خلال نافذة مدتها دقيقتان لكل من علامات:00 و:15 و:30 و:45 دقيقة.
تنفيذ التقييد من جانب الخادم
قم بتنفيذ التقييد من جانب الخادم لمراقبة وإدارة تدفق حركة المرور إلى FCM.
التعامل مع إعادة المحاولة
بينما تسعى FCM جاهدة لتكون متاحة بدرجة عالية، في بعض الأحيان تنتهي مهلة بعض الطلبات أو تفشل. على الرغم من اختلاف الأسباب، تعمل أفضل الممارسات التالية على تحسين سلوك إعادة المحاولة لتسليم الرسائل في أسرع وقت ممكن مع تقليل التأثير على الازدحام المروري.
المهلات
قم بتعيين مهلة لا تقل عن 10 ثوانٍ لطلبات الإرسال قبل إعادة المحاولة. تستخدم معظم استدعاءات الإجراءات عن بعد الداخلية الخاصة بـ FCM مهلة مدتها 10 ثوانٍ.
أخطاء
- بالنسبة للأخطاء 400، 401، 403، 404: قم بالإلغاء، ولا تقم بإعادة المحاولة.
- بالنسبة للأخطاء 429: أعد المحاولة بعد الانتظار للمدة المحددة في رأس إعادة المحاولة بعد. إذا لم يتم تعيين رأس إعادة المحاولة بعد، فسيتم تعيينه افتراضيًا على 60 ثانية.
- بالنسبة لـ 500 خطأ: أعد المحاولة مع التراجع الأسي.
التراجع الأسي
لتجنب إعادة محاولة التضخيم، قم بتنفيذ التراجع الأسي مع الارتعاش عند إعادة محاولة الطلبات. على سبيل المثال، تنفذ حزمة Firebase Admin SDK التراجع الأسي.
فيما يلي بعض الإعدادات الموصى بها:
- الحد الأدنى للفاصل الزمني: لا تقم بإعادة محاولة الطلب الفاشل على الفور مع FCM. انتظر 10 ثوانٍ على الأقل قبل إعادة محاولة الطلب الفاشل.
- الحد الأقصى للفاصل الزمني: قم بتعيين الحد الأقصى للفاصل الزمني لإسقاط الطلبات التي لم تعد في الوقت المناسب، بدلاً من إعادة المحاولة إلى أجل غير مسمى.
إذا تمت إعادة محاولة الطلب باستمرار مع التراجع الأسي وما زال يفشل بعد 60 دقيقة، فإما أنه تم تصنيفه بشكل خاطئ على أنه خطأ قابل لإعادة المحاولة، أو أن FCM تواجه انقطاعًا حيث قد تؤدي إعادة المحاولة إلى تفاقم الموقف عن غير قصد.
إنشاء خطط الطرح والتراجع، وإجراء تغييرات تدريجية
عند إجراء تغييرات واسعة النطاق على حركة المرور، مثل زيادة حركة المرور إلى FCM أو تحويل حركة المرور عبر المناطق أو الشبكات، فإن تصميم خطة الطرح/التراجع وتنفيذ التغييرات التدريجية سيؤدي إلى حماية المستخدمين وخدمتك وFCM.
- تعمل خطة الطرح على مواءمة التوقعات لأصحاب المصلحة. في بعض المواقف (الموضحة أدناه)، قد ترغب في مشاركة خطة الطرح الخاصة بك مسبقًا مع فريق FCM لتجنب المفاجآت.
- تسمح لك خطة التراجع باحتساب الحالات الطارئة وإعداد الآليات للتعافي بسرعة وأمان من حالات الفشل غير المتوقعة.
- إن إجراء التغييرات التدريجية له جانبان:
- التدرج التدريجي: يجب أن تكون الخطوات 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% أو أقل. " نقع " (مراقبة سلوك النظام تحت الحمل) في كل خطوة لمدة يوم واحد إلى أسبوع واحد. يتيح لك ذلك اكتشاف المشكلات المحتملة قبل "الخطوة التالية"
- زيادة تدريجية في حركة المرور: عند اتخاذ كل "خطوة" لزيادة حركة المرور، قم بتيسير حركة المرور على مدار ساعة على الأقل. يتيح ذلك للبنية الأساسية لموازنة التحميل الخاصة بـ FCM إمكانية توسيع نطاق حركة المرور الجديدة بشكل مناسب مع تقليل احتمالات نقاط الاتصال والازدحام.
فيما يلي سيناريو افتراضي لترحيل 500000 RPS عالميًا من FCM Legacy HTTP API إلى FCM HTTP v1 API:
| أسبوع | خطوة | استراتيجية التصعيد التدريجي |
|---|---|---|
| 0 | 1% زيادة | يمكنك زيادة السرعة بسلاسة من 0 إلى 5000 RPS إلى FCM HTTP v1 على مدار الساعة. |
| 1 | 5% زيادة | يمكنك زيادة السرعة بسلاسة من 5000 إلى 25000 دورة في الثانية خلال ساعتين. |
| 2 | 10% زيادة | يمكنك زيادة السرعة بسلاسة من 25000 إلى 50000 دورة في الثانية خلال ساعتين |
| 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 أشهر بمقياس 100000 دورة في الثانية على مستوى العالم أو 30000 دورة في الثانية على مستوى القارة.