چه در حال توسعه یک اپلیکیشن نوپا باشید و چه از قبل یک سرویس پرترافیک را اداره کنید، می‌توانید از بینش‌ها و توصیه‌های این راهنما در مورد چگونگی مقیاس‌پذیری روان با FCM بهره‌مند شوید. این مفاهیم و شیوه‌ها می‌توانند به شما کمک کنند تا از تأثیرات منفی هنگام نیاز به ارسال حجم زیادی از پیام‌ها جلوگیری کنید.
اصطلاحات و مفاهیم کلیدی
درخواست پیام : یک درخواست پیام FCM؛ که به جای «درخواست»، «پیام» یا «پرس‌وجو» استفاده می‌شود.
درخواست‌ها در هر ثانیه (RPS) : معیاری برای توصیف نرخ درخواست‌های ورودی به FCM؛ که به جای پرس‌وجوها در هر ثانیه (QPS) استفاده می‌شود.
توکن‌های سهمیه، سطل‌های توکن و شارژ مجدد : هنگام ارسال پیام‌ها در برابر API HTTP نسخه ۱ FCM، هر درخواست یک توکن سهمیه اختصاص داده شده را در یک پنجره زمانی مشخص مصرف می‌کند. این پنجره که " سطل توکن " نامیده می‌شود، در پایان پنجره زمانی دوباره پر می‌شود . به عنوان مثال: API نسخه ۱ HTTP برای هر سطل توکن ۱ دقیقه‌ای، ۶۰۰ هزار توکن سهمیه اختصاص می‌دهد که در پایان هر پنجره ۱ دقیقه‌ای دوباره پر می‌شود.
محدود کردن سرعت سرور : هنگامی که حجم ترافیک از ظرفیت سرویس FCM فراتر رود، درخواست‌های فراتر از ظرفیت سرویس‌دهی تا جریان ورودی با محدودیت سرعت رد می‌شوند. پاسخ‌های خطای 429 با هدرهای retry-after ممکن است برگردانده شوند تا نشان دهند که باید قبل از تلاش مجدد درخواست، مدت زمان مشخصی صبر کنید.
محدود کردن سرعت سمت کلاینت : وقتی کلاینت‌ها با شکست درخواست، تأخیر بالا یا خطای 429 مواجه می‌شوند، باید داوطلبانه سرعت جریان خروجی را محدود کنند تا از تشدید ازدحام جلوگیری شود.
عقب‌نشینی نمایی : هنگام تلاش مجدد برای خطاها، تأخیرهای زمانی را که به صورت نمایی افزایش می‌یابند، اضافه کنید. برای مثال: ۱ ثانیه، ۲ ثانیه، ۴ ثانیه، ۸ ثانیه، ۱۶ ثانیه، ۳۲ ثانیه و غیره.
لرزش (Jittering ): جلوگیری از درخواست‌های تلاش مجدد در فواصل زمانی دقیق. با لرزش، شما تأخیرهای تلاش مجدد را از طریق یک فرآیند تصادفی تغییر می‌دهید تا آنها را به طور یکنواخت در طول زمان توزیع کنید (به عنوان مثال: 0.9 ثانیه، 2.3 ثانیه، 4.1 ثانیه، 8.5 ثانیه، 17.9 ثانیه، 34.7 ثانیه).
تقویت تلاش مجدد : وقتی درخواست‌های ناموفق بدون وقفه/لرزش نمایی دوباره تلاش می‌شوند، اغلب انباشته شده و به بار ترافیک جاری می‌افزایند و به طور بالقوه مشکلات تراکم ترافیک را "تقویت" و تشدید می‌کنند.
مشکل: افزایش ناگهانی ترافیک
FCM میلیون‌ها درخواست در ثانیه (RPS) را پردازش می‌کند. بزرگترین عامل ایجاد ازدحام سیستمی، مشکلات تأخیر و قطعی‌ها، افزایش ناگهانی ترافیک است.
ترافیک سنگین چیست؟
انواع مختلفی از افزایش ناگهانی ترافیک وجود دارد.
افزایش ناگهانی ترافیک در طول ساعت: FCM در طول 30 ثانیه تا 2 دقیقه اول هر ساعت، بیش از دو برابر ترافیک دریافت می‌کند. افزایش ناگهانی ترافیک مشابه، البته کمتر، در ساعات نیم ساعت و ربع ساعت نیز مشاهده می‌شود (مثال‌ها: 00:15، 00:30، 00:45)
تقویت تلاش مجدد : تلاش مجدد برای درخواست‌های ناموفق یا با زمان انقضا بدون backoff نمایی می‌تواند به صورت موج‌های تکراری ترافیک روی اوج‌های ترافیکی موجود جمع شود.
تغییرات ناگهانی الگوی ترافیک: هدایت ترافیک جدید به FCM یا انتقال ترافیک به FCM در مناطق مختلف بدون در نظر گرفتن عوامل هموارکننده مانند افزایش تدریجی سرعت می‌تواند باعث افزایش ناگهانی شود.
استفاده از توکن سهمیه‌بندی در ابتدای پنجره‌های سهمیه‌بندی: استفاده از تمام توکن‌های سهمیه‌بندی در ابتدای پنجره‌های سهمیه‌بندی به جای پخش مساوی درخواست‌ها در سراسر پنجره‌های سهمیه‌بندی، نوسانات روشن-خاموش ایجاد می‌کند که متعادل‌سازی بار آنها دشوار و پرهزینه است.
رویدادهای ویژه: افزایش ترافیک در طول تعطیلات (شب سال نو) یا رویدادهای ورزشی ( جام جهانی فوتبال ).
با «مسطح کردن منحنی» می‌توان افزایش ناگهانی ترافیک را جبران کرد
این بخش، استراتژی‌هایی را برای کاهش افزایش ناگهانی ترافیک در صورت امکان شرح می‌دهد - استراتژی‌هایی برای «صاف کردن منحنی».
از FCM فقط برای موارد استفاده مناسب استفاده کنید
مواردی وجود دارد که استفاده از FCM برای ارسال اعلان ضروری یا مناسب نیست.
برای مثال، برای اعلان‌های رویدادهای تقویم، می‌توانید یک وظیفه محلی را در برنامه خود برنامه‌ریزی کنید تا در زمان‌های مناسب به جای ارسال اعلان از سرور برنامه، آن را نمایش دهد. پیام‌های FCM را به همگام‌سازی‌های تقویم محدود کنید.
از افزایش ناگهانی دما (spicks) خودداری کنید
یک الگوی ضد مقیاس‌پذیری این است که به جای اعمال محدودیت سمت سرور، اعلان‌های FCM را با حداکثر سرعتی که سیستم‌ها اجازه می‌دهند ارسال کنید. موارد زیر را در نظر بگیرید:
- آیا لازم است همه مشتریان شما در عرض یک دقیقه اعلان یکسانی دریافت کنند؟ آیا مثلاً یک بازه تحویل ۵ دقیقه‌ای هنوز هم نیازهای تجاری شما را برآورده می‌کند؟
- آیا می‌توان مشتریان شما را بر اساس اولویت تقسیم‌بندی کرد تا از افزایش ناگهانی قیمت‌ها جلوگیری شود؟
- آیا می‌توان اعلان‌های شما را از قبل برنامه‌ریزی کرد؟
هر جا که ممکن است : از استراتژی‌هایی که منجر به اتمام فوری سهمیه ارسال FCM شما می‌شوند، اجتناب کنید و به محض پر شدن مجدد سطل توکن، این الگو را تکرار کنید. این الگوی دسترسی، مشکلات تعادل بار را برای FCM و سیستم‌های وابسته به آن ایجاد می‌کند. ترافیک را تا حد امکان به تدریج افزایش دهید. حداقل، در یک بازه زمانی ۶۰ ثانیه‌ای، از ۰ به حداکثر RPS افزایش دهید. برای RPS بالاتر، بازه‌های زمانی طولانی‌تر را ترجیح دهید.
از ترافیک «سر ساعت» اجتناب کنید
در صورت امکان : از ارسال پیام در بازه زمانی ۲ دقیقه‌ای قبل از هر یک از دقایق ۰۰:۰۰، ۱۵:۱۵، ۳۰:۳۰ و ۴۵:۴۵ خودداری کنید.
پیاده‌سازی کنترل سرعت سمت سرور
برای نظارت و مدیریت جریان ترافیک به FCM، کنترل سرعت سمت سرور را پیاده‌سازی کنید.
مدیریت تلاش‌های مجدد
در حالی که FCM تلاش می‌کند تا در دسترس‌پذیری بالایی داشته باشد، گاهی اوقات برخی از درخواست‌ها با مشکل اتمام زمان یا عدم موفقیت مواجه می‌شوند. اگرچه دلایل این امر متفاوت است، اما بهترین شیوه‌های زیر، رفتار تلاش مجدد را بهینه می‌کنند تا پیام‌ها در اسرع وقت تحویل داده شوند و در عین حال تأثیر بر تراکم ترافیک به حداقل برسد.
تایم اوت‌ها
قبل از تلاش مجدد، حداقل یک مهلت زمانی ۱۰ ثانیه‌ای برای درخواست‌های ارسالی تنظیم کنید. اکثر فراخوانی‌های رویه از راه دور داخلی FCM از مهلت زمانی ۱۰ ثانیه‌ای استفاده می‌کنند.
خطاها
- برای خطاهای ۴۰۰، ۴۰۱، ۴۰۳، ۴۰۴: لغو کنید و دوباره امتحان نکنید.
- برای خطاهای ۴۲۹: پس از انتظار برای مدت زمان تعیین شده در سربرگ retry-after، دوباره امتحان کنید. اگر سربرگ retry-after تنظیم نشده باشد، پیش‌فرض روی ۶۰ ثانیه است.
- برای ۵۰۰ خطا: با backoff نمایی دوباره امتحان کنید.
عقب‌نشینی نمایی
برای جلوگیری از تکرار تلاش، برای درخواست‌های تلاش مجدد، از روش بازگشت نمایی (exponential back-off) به همراه لرزش (jittering) استفاده کنید. برای مثال، کیت توسعه نرم‌افزاری مدیریت فایربیس (Firebase Admin SDK) از روش بازگشت نمایی (exponential backoff) استفاده می‌کند.
در اینجا چند تنظیم پیشنهادی دیگر وجود دارد:
- حداقل فاصله زمانی: بلافاصله پس از شکست درخواست با FCM، آن را دوباره امتحان نکنید. حداقل 10 ثانیه قبل از امتحان مجدد درخواست ناموفق صبر کنید.
- حداکثر فاصله زمانی: به جای تلاش مجدد به طور نامحدود، حداکثر فاصله زمانی را برای حذف درخواست‌هایی که دیگر به موقع نیستند، تعیین کنید.
اگر یک درخواست به طور مداوم با backoff نمایی دوباره امتحان شود و 60 دقیقه بعد هنوز شکست بخورد، یا به اشتباه به عنوان یک خطای قابل امتحان مجدد طبقه‌بندی شده است، یا FCM دچار قطعی شده است که در آن ممکن است تلاش‌های مجدد سهواً وضعیت را بدتر کنند.
ایجاد برنامه‌های راه‌اندازی و بازگشت به عقب و اعمال تغییرات تدریجی
هنگام ایجاد تغییرات ترافیکی در مقیاس بزرگ، مانند افزایش ترافیک به FCM یا تغییر ترافیک در مناطق یا شبکه‌ها، طراحی یک برنامه‌ی راه‌اندازی/بازگشت و اجرای تغییرات تدریجی، از کاربران، سرویس و FCM شما محافظت خواهد کرد.
- یک طرح اجرایی، انتظارات ذینفعان را هماهنگ می‌کند. در شرایط خاص (که در ادامه مورد بحث قرار می‌گیرد)، ممکن است بخواهید طرح اجرایی خود را از قبل با تیم FCM به اشتراک بگذارید تا از غافلگیری جلوگیری شود.
- یک طرح بازگشت به عقب به شما امکان می‌دهد تا احتمالات را در نظر بگیرید و سازوکارهایی را برای بازیابی سریع و ایمن از خرابی‌های پیش‌بینی نشده آماده کنید.
- ایجاد تغییرات تدریجی دو جنبه دارد:
- افزایش «پله‌ای»: مراحل باید ۱٪ -> ۵٪ -> ۱۰٪ -> ۲۵٪ -> ۵۰٪ -> ۷۵٪ -> ۱۰۰٪ یا دقیق‌تر باشد. هر مرحله را به مدت ۱ روز تا ۱ هفته « خیساندن » (مشاهده رفتار سیستم تحت بار) انجام دهید. این به شما امکان می‌دهد مشکلات احتمالی را قبل از «افزایش» بعدی تشخیص دهید.
- افزایش تدریجی ترافیک: هنگام برداشتن هر "گام" برای افزایش ترافیک، ترافیک را در طول حداقل یک ساعت روان کنید. این به زیرساخت متعادل‌سازی بار FCM اجازه می‌دهد تا ترافیک جدید شما را به طور مناسب مقیاس‌بندی کند و در عین حال احتمال ایجاد نقاط حساس و ازدحام را به حداقل برساند.
در اینجا یک سناریوی فرضی برای مهاجرت سراسری ۵۰۰۰۰۰ RPS از FCM Legacy HTTP API به FCM HTTP v1 API ارائه شده است:
| هفته | قدم | استراتژی افزایش تدریجی |
|---|---|---|
| 0 | افزایش ۱ درصدی | در طول یک ساعت، سرعت را به آرامی از 0 تا 5000 RPS به FCM HTTP v1 افزایش دهید. |
| ۱ | افزایش ۵ درصدی | افزایش تدریجی سرعت از ۵۰۰۰ به ۲۵۰۰۰ دور در ثانیه طی ۲ ساعت. |
| ۲ | افزایش ۱۰ درصدی | افزایش تدریجی سرعت از ۲۵۰۰۰ به ۵۰۰۰۰ دور در ثانیه طی ۲ ساعت |
| ۳ | افزایش ۲۵ درصدی | افزایش سرعت از ۵۰،۰۰۰ به ۱۲۵،۰۰۰ دور در ثانیه طی ۳ ساعت |
| ۴ | افزایش ۵۰ درصدی | افزایش سرعت از ۱۲۵۰۰۰ به ۲۵۰۰۰۰ دور در ثانیه طی ۶ ساعت |
| ۵ | افزایش ۷۵ درصدی | افزایش سرعت از ۲۵۰،۰۰۰ به ۳۷۵،۰۰۰ دور در ثانیه طی ۶ ساعت |
| ۶ | افزایش ۱۰۰ درصدی | افزایش سرعت از ۳۷۵۰۰۰ به ۵۰۰۰۰۰ دور در ثانیه طی ۶ ساعت |
طرح فرضی بازگشت به عقب:
- اگر تأخیر ۹۵ درصدی به بیش از ۵۰۰ میلی‌ثانیه افزایش یابد یا اگر نسبت خطا برای بیش از یک ساعت در هر مرحله از ۱٪ بیشتر شود، از پیکربندی پویا برای بازگشت فوری به مرحله قبل استفاده کنید.
- بازگشت به مراحل قبلی را تا زمانی که تأخیر و نسبت خطا به سطوح اسمی بازگردند، ادامه دهید.
چه زمانی با FCM تماس بگیریم؟
در صورت وجود هر یک از موارد زیر، از طریق پشتیبانی Firebase با FCM تماس بگیرید:
- سهمیه‌های پیش‌فرض دیگر مورد استفاده شما را برآورده نمی‌کنند
- شما الگوهای ارسال خود را در یک بازه زمانی ۳ ماهه در مقیاس ۱۰۰۰۰۰ RPS در سطح جهانی یا ۳۰۰۰۰ RPS در سطح قاره‌ای تغییر می‌دهید.