چه درحال توسعه برنامه‌ای نوپا باشید و چه درحال اجرای سرویسی با ترافیک بالا، می‌توانید از اطلاعات آماری و توصیه‌های این راهنما درباره نحوه مقیاس‌بندی آسان با FCM بهره‌مند شوید. این مفاهیم و روال‌ها می‌توانند به شما کمک کنند وقتی نیاز به ارسال حجم زیادی از پیام‌ها دارید از تأثیرات منفی جلوگیری کنید.
اصطلاحات و مفاهیم کلیدی
درخواست پیام: درخواست پیام FCM؛ به‌صورت متقابل با «درخواست»، «پیام»، یا «پُرسمان» استفاده می‌شود.
درخواست در ثانیه (RPS): سنجه‌ای برای توصیف نرخ درخواست‌های ورودی به FCM؛ به‌جای «پُرسمان در ثانیه» (QPS) نیز استفاده می‌شود.
«واحد سهمیه»، «واحد سهمیه دسته‌بندی‌شده»، و «تکمیل»: هنگام ارسال پیام دربرابر FCM HTTP v1 API، هر درخواست در یک بازه زمانی معین، یک واحد سهمیه اختصاص‌یافته را مصرف می‌کند. این پنجره که «سطل نشان» نامیده می‌شود، در پایان پنجره زمانی دوباره پر می‌شود. برای مثال: «میانای برنامه‌سازی کاربردی HTTP نسخه ۱» برای هر «ظرف نشان یک‌دقیقه‌ای» ۶۰۰ هزار «نشان سهمیه» اختصاص می‌دهد که در پایان هر بازه یک‌دقیقه‌ای دوباره پر می‌شود.
کنترل حجم ترافیک در سمت سرور: وقتی حجم ترافیک از ظرفیت سرویس FCM فراتر رود، درخواست‌های فراتر از ظرفیت سرویس برای محدود کردن نرخ جریان ورودی رد می‌شوند. پاسخ‌های خطای 429 با سرایندهای retry-after ممکن است برگردانده شوند تا نشان دهند
که باید مدت زمان مشخصی صبر کنید و سپس درخواست را دوباره امتحان کنید.
محدودسازی سمت مشتری: وقتی مشتریان با خطاهای درخواست، تأخیر بالا، یا
خطاهای 429 مواجه می‌شوند، باید به‌صورت داوطلبانه جریان خروجی را محدود کنند تا از تشدید
ازدحام جلوگیری کنند.
عقب‌گرد نمایی: هنگام تلاش مجدد برای رفع خطاها، تأخیرهای زمانی را به‌صورت نمایی افزایش دهید. برای مثال: ۱ ثانیه، ۲ ثانیه، ۴ ثانیه، ۸ ثانیه، ۱۶ ثانیه، ۳۲ ثانیه، و غیره.
لرزش: اجتناب از تلاش مجدد برای درخواست‌ها در فواصل زمانی دقیق. با لرزش، تأخیرهای تلاش مجدد را ازطریق فرایندی تصادفی تغییر می‌دهید تا آن‌ها را به‌طور یکنواخت در طول زمان توزیع کنید (برای مثال: ۰٫۹ ثانیه، ۲٫۳ ثانیه، ۴٫۱ ثانیه، ۸٫۵ ثانیه، ۱۷٫۹ ثانیه، ۳۴٫۷ ثانیه).
تقویت تلاش مجدد: وقتی درخواست‌های ناموفق بدون عقب‌گرد نمایی/لرزش مجدد امتحان می‌شوند، اغلب انباشته می‌شوند و به بار ترافیک جاری اضافه می‌کنند و به‌طور بالقوه مشکلات ازدحام ترافیک را «تقویت» و تشدید می‌کنند.
مشکل: افزایش ناگهانی ترافیک
FCM میلیون‌ها درخواست در ثانیه (RPS) را پردازش می‌کند. بزرگ‌ترین عامل ایجاد ازدحام سیستم، مشکلات تأخیر، و قطعی‌ها، جهش‌های ترافیک است.
ترافیک جهشی چیست؟
چندین نوع مختلف از جهش ترافیک وجود دارد.
اوج‌های سر ساعت: FCM در ۳۰ ثانیه تا ۲ دقیقه اول هر ساعت، بیش‌از دو برابر ترافیک دریافت می‌کند. افزایش‌های مشابه، هرچند کمتر، نیز در نشان‌های نیم‌ساعت و ربع ساعت مشاهده می‌شود (مثال: ۰۰:۱۵، ۰۰:۳۰، ۰۰:۴۵)
تلاش مجدد برای تقویت: تلاش مجدد برای درخواست‌های ناموفق یا منقضی‌شده بدون پس‌گیری نمایی می‌تواند به موج‌های تکراری ترافیک در بالای قله‌های ترافیک موجود منجر شود.
تغییرات ناگهانی الگوی ترافیک: هدایت ترافیک جدید به FCM یا انتقال ترافیک به FCM در مناطق مختلف بدون عوامل هموارسازی مانند افزایش تدریجی می‌تواند باعث ایجاد جهش شود.
استفاده از نشان سهمیه در ابتدای بازه سهمیه: استفاده از همه نشان‌های سهمیه در ابتدای بازه‌های سهمیه به‌جای توزیع یکنواخت درخواست‌ها در سراسر بازه‌های سهمیه، نوسانات روشن/خاموش ایجاد می‌کند که تراز کردن بار آن‌ها دشوار و پرهزینه است.
رویدادهای ویژه: افزایش ناگهانی ترافیک درطول تعطیلات (شب سال نو) یا رویدادهای ورزشی (جام جهانی فیفا).
با «مسطح کردن منحنی»، اوج‌های ترافیک را اصلاح کنید
این بخش استراتژی‌هایی را برای هموار کردن اوج‌های ترافیک درصورت امکان شرح می‌دهد—استراتژی‌هایی برای «مسطح کردن منحنی».
از FCM فقط برای موارد استفاده مناسب استفاده کنید
در برخی موارد استفاده، استفاده از FCM برای ارائه اعلان ضروری یا مناسب نیست.
برای مثال، برای اعلان‌های رویداد تقویم، می‌توانید تکلیف محلی را در برنامه‌تان زمان‌بندی کنید تا اعلان را در زمان‌های مناسب به‌جای ارسال از سرور برنامه نمایش دهد. پیام‌های FCM را به همگام‌سازی‌های تقویم محدود کنید.
پرهیز از اوج‌ها
یکی از الگوهای ضد مقیاس‌بندی این است که اعلان‌های FCM را به‌سرعت سیستم‌ها ارسال کنید به‌جای اینکه از محدودسازی سمت سرور استفاده کنید. موارد زیر را درنظر بگیرید:
- آیا همه مشتریان شما باید اعلان یکسانی را در بازه زمانی ۱ دقیقه‌ای دریافت کنند؟ آیا پنجره زمانی ۵ دقیقه‌ای برای تحویل، برای مثال، همچنان نیازهای کسب‌وکارتان را برآورده می‌کند؟
- آیا مشتریان شما می‌توانند براساس اولویت بخش‌بندی شوند تا اوج‌ها را هموار کنند؟
- آیا اعلان‌های شما را می‌توان ازقبل زمان‌بندی کرد؟
درصورت امکان: از استراتژی‌هایی که منجر به اتمام فوری سهمیه ارسال FCM شما می‌شوند، اجتناب کنید و به‌محض پر شدن مجدد ظرفیت نشان، الگو را تکرار نکنید. این الگوی دسترسی برای FCM و سیستم‌های وابسته آن مشکلات تراز بار ایجاد می‌کند. ترافیک را تا حد امکان به‌تدریج افزایش دهید. حداقل، در یک بازه زمانی ۶۰ ثانیه‌ای، از ۰ به حداکثر درخواست در ثانیه افزایش دهید. برای «درخواست در ثانیه» بالاتر، پنجره‌های طولانی‌تر را ترجیح دهید.
پرهیز از ترافیک «سر ساعت»
درصورت امکان: از ارسال پیام در بازه زمانی ۲ دقیقه‌ای از هریک از نشان‌های :۰۰، :۱۵، :۳۰، و :۴۵ دقیقه خودداری کنید.
پیاده‌سازی محدودسازی سمت سرور
برای نظارت و مدیریت جریان ترافیک به FCM، محدودیت سمت سرور را پیاده‌سازی کنید.
درحال مدیریت تلاش‌های مجدد
اگرچه FCM تلاش می‌کند تا حد امکان دردسترس باشد، اما گاهی اوقات برخی‌از درخواست‌ها با اتمام زمان مواجه می‌شوند یا ناموفق می‌شوند. اگرچه دلایل متفاوت است، اما روال‌های مطلوب زیر رفتار تلاش مجدد را بهینه‌سازی می‌کنند تا پیام‌ها را در اسرع وقت ارسال کنند و درعین‌حال تأثیر بر ازدحام ترافیک را به حداقل برسانند.
درنگ
پیش‌از تلاش مجدد، حداقل ۱۰ ثانیه زمان انتظار برای درخواست‌های ارسال تنظیم کنید. اکثر «فراخوان‌های رویه‌ای از دور» داخلی FCM از مهلت زمانی ۱۰ ثانیه‌ای استفاده می‌کنند.
خطاها
- برای خطاهای ۴۰۰، ۴۰۱، ۴۰۳، ۴۰۴: لغو کنید و دوباره امتحان نکنید.
- برای خطاهای ۴۲۹: پس‌از مدت زمان تعیین‌شده در سرصفحه retry-after دوباره امتحان کنید. اگر سرصفحه retry-after تنظیم نشده باشد، به‌طور پیش‌فرض ۶۰ ثانیه درنظر گرفته می‌شود.
- برای خطاهای ۵۰۰: با عقب‌گرد نمایی دوباره امتحان کنید.
پس‌گیری نمایی
برای جلوگیری از تقویت تلاش مجدد، عقب‌گرد نمایی با لرزش برای تلاش مجدد درخواست‌ها پیاده‌سازی کنید. برای مثال، Firebase Admin SDK پس‌گیری نمایی را پیاده‌سازی می‌کند.
در اینجا چند تنظیمات توصیه‌شده دیگر آمده است:
- حداقل فاصله: درخواست ناموفق را بلافاصله با FCM دوباره امتحان نکنید. پیش‌از تلاش مجدد برای درخواست ناموفق، حداقل ۱۰ ثانیه صبر کنید.
- حداکثر فاصله: به‌جای تلاش مجدد نامحدود، حداکثر فاصله‌ای برای حذف درخواست‌هایی که دیگر به‌موقع نیستند تنظیم کنید.
اگر درخواستی به‌طور مداوم با عقب‌گرد نمایی امتحان مجدد شود و همچنان ۶۰ دقیقه بعد ناموفق باشد، یا به‌عنوان خطای قابل‌امتحان مجدد طبقه‌بندی اشتباه شده است یا FCM با قطعی مواجه است که در آن امتحان مجدد ممکن است وضعیت را ناخواسته بدتر کند.
طرح‌های عرضه و بازگرداندن ایجاد کنید و تغییرات تدریجی اعمال کنید
هنگام ایجاد تغییرات ترافیک در مقیاس بزرگ، مانند افزایش ترافیک به FCM یا انتقال ترافیک بین مناطق یا شبکه‌ها، طراحی یک طرح عرضه/برگرداندن و اجرای تغییرات تدریجی از کاربران، سرویس، و FCM شما محافظت می‌کند.
- طرح عرضه انتظارات ذی‌نفعان را هماهنگ می‌کند. در شرایط خاص (که در زیر بحث شده است)، ممکن است بخواهید طرح عرضه خود را ازقبل با تیم FCM هم‌رسانی کنید تا از بروز غافلگیری جلوگیری کنید.
- طرح بازگشت به عقب به شما امکان می‌دهد برای شرایط احتمالی حساب کنید و سازوکارهایی را برای بازیابی سریع و ایمن از خرابی‌های غیرمنتظره آماده کنید.
- ایجاد تغییرات تدریجی دو جنبه دارد:
- افزایش تدریجی: مراحل باید ۱٪ -> ۵٪ -> ۱۰٪ -> ۲۵٪ -> ۵۰٪ -> ۷۵٪ -> ۱۰۰٪ یا دقیق‌تر باشد. هر مرحله را به‌مدت ۱ روز تا ۱ هفته «خیس کنید» (عملکرد سیستم را تحت بار مشاهده کنید). این به شما امکان می‌دهد مشکلات احتمالی را قبل‌از «گام بعدی» تشخیص دهید
- افزایش تدریجی ترافیک: هنگام برداشتن هر «گام» برای افزایش ترافیک، ترافیک را در بازه زمانی حداقل یک ساعت هموار کنید. این کار به زیرساخت تراز بار FCM اجازه می‌دهد تا ترافیک جدید شما را به‌طور مناسب مقیاس‌بندی کند و درعین‌حال احتمال نقاط داغ و ازدحام را به حداقل برساند.
در اینجا یک سناریو فرضی برای انتقال ۵۰۰٬۰۰۰ درخواست در ثانیه در سطح جهانی از FCM Legacy HTTP API به FCM HTTP v1 API آورده شده است:
| هفته | مرحله | استراتژی افزایش تدریجی |
|---|---|---|
| 0 | ٪۱ بهینه‌سازی عملکرد | طی یک ساعت، به‌تدریج از ۰ به ۵٬۰۰۰ درخواست در ثانیه به FCM HTTP v1 افزایش دهید. |
| 1 | ٪۵ بهینه‌سازی عملکرد | به‌تدریج از ۵٬۰۰۰ به ۲۵٬۰۰۰ درخواست در ثانیه درطول ۲ ساعت افزایش دهید. |
| 2 | ٪۱۰ آماده‌سازی | به‌تدریج از ۲۵٬۰۰۰ به ۵۰٬۰۰۰ درخواست در ثانیه درطول ۲ ساعت افزایش دهید |
| 3 | ٪۲۵ افزایش تدریجی | افزایش تدریجی از ۵۰٬۰۰۰ به ۱۲۵٬۰۰۰ درخواست در ثانیه طی ۳ ساعت |
| 4 | آماده‌سازی ۵۰٪ | افزایش تدریجی از ۱۲۵٬۰۰۰ به ۲۵۰٬۰۰۰ درخواست در ثانیه طی ۶ ساعت |
| 5 | ٪۷۵ افزایش تدریجی | افزایش تدریجی از ۲۵۰٬۰۰۰ به ۳۷۵٬۰۰۰ درخواست در ثانیه طی ۶ ساعت |
| 6 | ٪۱۰۰ آماده‌سازی | افزایش تدریجی از ۳۷۵٬۰۰۰ به ۵۰۰٬۰۰۰ درخواست در ثانیه طی ۶ ساعت |
طرح فرضی بازگرداندن:
- اگر تأخیر صدک ۹۵ به بیش‌از ۵۰۰ میلی‌ثانیه افزایش یابد یا اگر نسبت خطا در هر مرحله‌ای بیش‌از یک ساعت از ۱٪ فراتر رود، از پیکربندی پویا برای بازگرداندن فوری به مرحله قبلی استفاده کنید.
- بازگرداندن به مراحل قبلی را ادامه دهید تا زمانی که تأخیر و نسبت خطا به سطوح اسمی بازگردد.
زمان تماس با FCM
اگر هریک از موارد زیر صدق می‌کند، ازطریق پشتیبانی Firebase با FCM تماس بگیرید:
- سهمیه‌های پیش‌فرض دیگر با مورد استفاده شما مطابقت ندارد
- الگوهای ارسال خود را در یک بازه ۳ ماهه در مقیاس ۱۰۰٬۰۰۰ درخواست در ثانیه در سطح جهانی یا ۳۰٬۰۰۰ درخواست در ثانیه در سطح قاره‌ای تغییر می‌دهید.