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