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