چه درحال توسعه برنامه‌ای نوپا باشید و چه درحال اجرای سرویسی با ترافیک بالا، می‌توانید از اطلاعات آماری و توصیه‌های این راهنما درباره نحوه مقیاس‌بندی آسان با FCM بهره‌مند شوید. این مفاهیم و روال‌ها می‌توانند به شما کمک کنند وقتی نیاز به ارسال حجم زیادی از پیام‌ها دارید از تأثیرات منفی جلوگیری کنید.
اصطلاحات و مفاهیم کلیدی
درخواست پیام: درخواست پیام FCM؛ به‌صورت متقابل با «درخواست»، «پیام»، یا «پُرسمان» استفاده می‌شود.
درخواست در ثانیه (RPS): سنجه‌ای برای توصیف نرخ درخواست‌های ورودی به FCM؛ به‌جای «پُرسمان در ثانیه» (QPS) نیز استفاده می‌شود.
«واحد سهمیه»، «واحد سهمیه دسته‌بندی‌شده»، و «تکمیل»: هنگام ارسال پیام دربرابر FCM HTTP v1 API، هر درخواست در یک بازه زمانی معین، یک واحد سهمیه اختصاص‌یافته را مصرف می‌کند. این پنجره که «سطل نشان» نامیده می‌شود، در پایان پنجره زمانی دوباره پر می‌شود. برای مثال: HTTP v1 API برای هر «سطل کد» ۱ دقیقه‌ای، ۶۰۰ هزار «کد سهمیه» اختصاص می‌دهد که در پایان هر پنجره ۱ دقیقه‌ای دوباره پر می‌شود.
کنترل حجم ترافیک در سمت سرور: وقتی حجم ترافیک از ظرفیت سرویس FCM فراتر رود، درخواست‌های فراتر از ظرفیت سرویس برای محدود کردن نرخ جریان ورودی رد می‌شوند. ممکن است پاسخ‌های خطای 429 با سرصفحه‌های retry-after برگردانده شود تا نشان دهد
که باید قبل‌از امتحان مجدد درخواست، مدت زمان مشخصی صبر کنید.
محدود کردن نرخ سمت کارخواه: وقتی کارخواه‌ها با خطاهای درخواست، تأخیر زیاد،
یا خطاهای 429 مواجه می‌شوند، باید به‌طور داوطلبانه نرخ جریان خروجی را محدود کنند تا از تشدید
ازدحام جلوگیری شود.
عقب‌گرد نمایی: هنگام امتحان مجدد خطاها، تأخیرهای زمانی را به‌صورت نمایی افزایش دهید. برای مثال: ۱ ثانیه، ۲ ثانیه، ۴ ثانیه، ۸ ثانیه، ۱۶ ثانیه، ۳۲ ثانیه، و غیره.
لرزش: اجتناب از تکرار درخواست‌ها در فواصل زمانی دقیق. با لرزش، تأخیرهای تکرار مجدد را ازطریق فرایندی تصادفی تغییر می‌دهید تا آن‌ها را به‌طور یکنواخت درطول زمان توزیع کنید (برای مثال: ۰٫۹ ثانیه، ۲٫۳ ثانیه، ۴٫۱ ثانیه، ۸٫۵ ثانیه، ۱۷٫۹ ثانیه، ۳۴٫۷ ثانیه).
تقویت امتحان مجدد: وقتی درخواست‌های ناموفق بدون عقب‌گرد نمایی/لرزش امتحان مجدد می‌شوند، اغلب انباشته می‌شوند و به بار ترافیک جاری اضافه می‌شوند، که به‌طور بالقوه مشکلات ازدحام ترافیک را «تقویت» و تشدید می‌کند.
مشکل: جهش ترافیک
FCM میلیون‌ها درخواست در ثانیه (RPS) را پردازش می‌کند. بزرگ‌ترین عامل ازدحام سیستماتیک، مشکلات تأخیر، و قطعی، جهش ترافیک است.
ترافیک جهشی چیست؟
چندین نوع مختلف از جهش ترافیک وجود دارد.
اوج‌های سر ساعت: FCM در ۳۰ ثانیه تا ۲ دقیقه اول هر ساعت، بیش‌از دو برابر ترافیک دریافت می‌کند. اوج‌های مشابه، هرچند کمتر، در نشان‌های نیم‌ساعت و ربع‌ساعت نیز مشاهده می‌شود (مثال: ۰۰:۱۵، ۰۰:۳۰، ۰۰:۴۵)
تقویت تلاش مجدد: تلاش مجدد برای درخواست‌های ناموفق یا منقضی‌شده بدون عقب‌نشینی نمایی می‌تواند به‌صورت موج‌های تکراری ترافیک روی قله‌های ترافیک موجود انباشته شود.
تغییرات ناگهانی الگوی ترافیک: هدایت ترافیک جدید به FCM یا انتقال ترافیک به FCM در مناطق مختلف بدون عوامل هموارسازی مانند افزایش تدریجی می‌تواند باعث ایجاد جهش شود.
استفاده از توکن سهمیه بارگذاری اولیه: تمام کردن همه توکن‌های سهمیه در شروع پنجره‌های سهمیه به‌جای توزیع یکنواخت درخواست‌ها در سراسر پنجره‌های سهمیه، نوسانات روشن-خاموش ایجاد می‌کند که متعادل‌سازی بار را دشوار و پرهزینه می‌کند.
رویدادهای ویژه: افزایش ناگهانی ترافیک درطول تعطیلات (شب سال نو) یا رویدادهای ورزشی (جام جهانی فیفا).
با «مسطح کردن منحنی» جهش‌های ترافیک را اصلاح کنید
این بخش استراتژی‌هایی را برای هموار کردن اوج‌های ترافیک درصورت امکان شرح می‌دهد—استراتژی‌هایی برای «مسطح کردن منحنی».
از FCM فقط برای موارد استفاده مناسب استفاده کنید
در برخی‌از موارد استفاده، استفاده از FCM برای ارسال اعلان ضروری یا مناسب نیست.
برای مثال، برای اعلان‌های رویداد تقویم، می‌توانید تکلیف محلی را در برنامه‌تان زمان‌بندی کنید تا به‌جای ارسال آن از سرور برنامه، اعلان را در زمان‌های مناسب نمایش دهد. پیام‌های FCM را به همگام‌سازی‌های تقویم محدود کنید.
پرهیز از اوج‌ها
یکی از الگوهای ضد مقیاس‌بندی این است که اعلان‌های FCM را به‌سرعت سیستم‌ها ارسال کنید به‌جای اینکه از محدودسازی سمت سرور استفاده کنید. موارد زیر را درنظر بگیرید:
- آیا همه مشتریانتان باید اعلان یکسانی را در بازه زمانی ۱ دقیقه‌ای دریافت کنند؟ برای مثال، آیا بازه زمانی تحویل ۵ دقیقه‌ای همچنان نیازهای کسب‌وکارتان را برآورده می‌کند؟
- آیا مشتریان شما می‌توانند براساس اولویت بخش‌بندی شوند تا جهش‌ها را هموار کنند؟
- آیا اعلان‌های شما می‌تواند ازقبل زمان‌بندی شود؟
هرجا ممکن بود: از استراتژی‌هایی که منجر به اتمام فوری سهمیه ارسال FCM شما می‌شود اجتناب کنید، فقط به‌محض پر شدن مجدد سطل توکن، الگو را تکرار کنید. این الگوی دسترسی مشکلات توازن بار برای FCM و سیستم‌های وابسته به آن ایجاد می‌کند. ترافیک را تا حد امکان به‌تدریج افزایش دهید. حداقل، از ۰ تا حداکثر درخواست در ثانیه را در یک پنجره زمانی ۶۰ ثانیه‌ای افزایش دهید. برای RPS بالاتر، بازه‌های زمانی طولانی‌تر را ترجیح دهید.
از ترافیک «سر ساعت» اجتناب کنید
درصورت امکان: از ارسال پیام در بازه زمانی ۲ دقیقه‌ای از هریک از نشان‌های :۰۰، :۱۵، :۳۰، و :۴۵ دقیقه خودداری کنید.
پیاده‌سازی محدودسازی سمت سرور
برای نظارت و مدیریت جریان ترافیک به 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 تماس بگیرید:
- سهمیه‌های پیش‌فرض دیگر با مورد استفاده شما مطابقت ندارد
- الگوهای ارسال خود را در یک بازه زمانی ۳ ماهه در مقیاس ۱۰۰٬۰۰۰ درخواست در ثانیه در سطح جهانی یا ۳۰٬۰۰۰ درخواست در ثانیه در سطح قاره‌ای تغییر می‌دهید.