چه درحال توسعه برنامه‌ای نوپا باشید یا درحال‌حاضر سرویسی با ترافیک بالا را اجرا می‌کنید، می‌توانید از اطلاعات آماری و توصیه‌های این راهنما در��اره نحوه مقیاس‌بندی هموار با 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 و سیستم‌های وابسته به آن ایجاد می‌کند. ترافیک را تا حد امکان به‌تدریج افزایش دهید. حداقل، از ۰ تا حداکثر درخواست در ثانیه را در یک پنجره زمانی ۶۰ ثانیه‌ای افزایش دهید. برای نرخ تبدیل بالاتر، بازه‌های زمانی طولانی‌تر را ترجیح دهید.
از ترافیک «سر ساعت» اجتناب کنید
درصورت امکان: از ارسال پیام در بازه زمانی ۲ دقیقه‌ای از هریک از نشان‌های :00، :15، :30، و :45 دقیقه خودداری کنید.
پیاده‌سازی کردن محدودسازی سمت سرور
برای نظارت و مدیریت جریان ترافیک به 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 تماس بگیرید:
- سهمیه‌های پیش‌فرض دیگر با مورد استفاده شما مطابقت ندارد
- الگوهای ارسال خود را در یک بازه زمانی ۳ ماهه در مقیاس ۱۰۰٬۰۰۰ درخواست در ثانیه در سطح جهانی یا ۳۰٬۰۰۰ درخواست در ثانیه در سطح قاره‌ای تغییر می‌دهید.