چه در حال توسعه یک برنامه نوپا یا در حال اجرای یک سرویس پرترافیک هستید، می‌توانید از بینش‌ها و توصیه‌های این راهنما در مورد نحوه مقیاس‌پذیری هموار با FCM بهره‌مند شوید. این مفاهیم و شیوه‌ها می‌توانند به شما در جلوگیری از تأثیرات منفی در هنگام نیاز به ارسال حجم زیادی از پیام کمک کنند.
درخواست پیام : درخواست پیام FCM. به جای "درخواست"، "پیام" یا "پرس و جو" استفاده می شود.
درخواست‌ها در هر ثانیه (RPS) : معیاری برای توصیف نرخ درخواست‌های دریافتی به FCM. به جای Queries-per-second (QPS) استفاده می شود.
Quota Tokens، Token Buckets و Refills : هنگام ارسال پیام‌ها علیه API FCM HTTP v1، هر درخواست در یک پنجره زمانی معین، یک Quota Token اختصاص داده شده را مصرف می‌کند. این پنجره که " سطل توکن " نامیده می شود، در پایان پنجره زمانی دوباره پر می شود . برای مثال: HTTP v1 API 600K Token Quota را برای هر سطل توکن 1 دقیقه ای اختصاص می دهد که در پایان هر پنجره 1 دقیقه ای دوباره پر می شود.
Throttling سمت سرور : زمانی که حجم ترافیک از ظرفیت سرویس FCM بیشتر شود، درخواست‌های فراتر از ظرفیت سرویس دهی به جریان ورودی با نرخ محدود رد می‌شوند. ممکن است 429 پاسخ خطا با سرصفحه‌های retry-after برگردانده شود تا نشان دهد که باید قبل از امتحان مجدد درخواست، یک دوره زمانی معین صبر کنید.
درگیری سمت مشتری : هنگامی که مشتریان شکست درخواست، تأخیر بالا یا خطاهای 429 را مشاهده می کنند، باید به طور داوطلبانه جریان خروج را محدود کنند تا از تشدید تراکم جلوگیری کنند.
عقب نشینی نمایی : هنگام امتحان مجدد خطاها، تأخیرهای زمانی را به طور تصاعدی اضافه کنید. به عنوان مثال: 1s، 2s، 4s، 8s، 16s، 32s.
بی قراری : اجتناب از تلاش مجدد درخواست ها در فواصل زمانی دقیق. با لرزش، تاخیرهای تلاش مجدد را از طریق یک فرآیند تصادفی تغییر می دهید تا آنها را به طور یکنواخت در طول زمان توزیع کنید (به عنوان مثال: 0.9s، 2.3s، 4.1s، 8.5s، 17.9s، 34.7s).
تقویت مجدد : هنگامی که درخواست‌های ناموفق بدون عقب‌نشینی/تقویت تصاعدی دوباره امتحان می‌شوند، اغلب انباشته می‌شوند و به بار ترافیک مداوم اضافه می‌شوند، که به طور بالقوه باعث "تقویت" و تشدید مشکلات تراکم ترافیک می‌شوند.
FCM میلیون ها درخواست را در ثانیه پردازش می کند (RPS). بزرگترین عامل ازدحام سیستمیک، مشکلات تأخیر و خاموشی، افزایش ترافیک است.
انواع مختلفی از افزایش ترافیک وجود دارد.
افزایش در ساعت: FCM در طول 30 ثانیه تا 2 دقیقه اول هر ساعت بیش از دو برابر ترافیک دریافت می کند. جهش‌های مشابه، هرچند کمتر، در علامت‌های نیم ساعت و ربع ساعت نیز مشاهده می‌شود (مثلاً: 00:15، 00:30، 00:45)
تلاش مجدد برای تقویت : تلاش مجدد درخواست های ناموفق یا با اتمام زمان بدون عقب نشینی نمایی می تواند در امواج تکراری ترافیک در بالای تاج های ترافیک موجود جمع شود.
تغییرات ناگهانی الگوی ترافیک: هدایت ترافیک جدید به FCM یا انتقال ترافیک به FCM در سراسر مناطق بدون هموارسازی عواملی مانند افزایش تدریجی می‌تواند باعث افزایش ناگهانی شود.
استفاده از نشانه سهمیه بارگیری از جلو: پایان دادن به تمام نشانه‌های سهمیه در شروع پنجره‌های سهمیه به جای پخش یکنواخت درخواست‌ها در پنجره‌های سهمیه، نوسان‌های روشن و خاموشی ایجاد می‌کند که تعادل بار دشوار و پرهزینه است.
رویدادهای ویژه: افزایش ترافیک در طول تعطیلات (شب سال نو) یا رویدادهای ورزشی ( جام جهانی فیفا ).
این بخش راهبردهایی را برای هموارسازی نوسانات ترافیکی در صورت امکان توضیح می‌دهد - استراتژی‌هایی برای "صاف کردن منحنی".
مواردی وجود دارد که استفاده از FCM برای ارسال اعلان ضروری یا مناسب نیست.
به عنوان مثال، برای اعلان‌های رویداد تقویم، می‌توانید یک کار محلی را در برنامه خود برنامه‌ریزی کنید تا به جای ارسال اعلان از سرور برنامه، اعلان را در زمان‌های مناسب نمایش دهد. پیام‌های FCM را به همگام‌سازی‌های تقویم محدود کنید.
یک ضد الگوی مقیاس‌پذیری، ارسال اعلان‌های FCM با سرعتی که سیستم‌ها اجازه می‌دهند، به جای اعمال فشار سمت سرور است. موارد زیر را در نظر بگیرید:
- آیا همه مشتریان شما نیاز به دریافت یک اعلان در عرض یک دقیقه دارند؟ به عنوان مثال، یک پنجره تحویل 5 دقیقه ای همچنان نیازهای کسب و کار شما را برآورده می کند؟
- آیا می‌توان مشتریان شما را بر اساس اولویت تقسیم‌بندی کرد تا همواری‌ها نسبت به افزایش قیمت‌ها انجام شود؟
- آیا می توان اعلان های شما را از قبل برنامه ریزی کرد؟
تا جایی که ممکن است : از استراتژی هایی که منجر به تخلیه فوری سهمیه ارسال FCM شما می شود، اجتناب کنید، فقط به محض اینکه سطل توکن شما دوباره پر شد، الگو را تکرار کنید. این الگوی دسترسی مشکلات متعادل سازی بار را برای FCM و سیستم های وابسته به آن ایجاد می کند. ترافیک را تا حد امکان به تدریج افزایش دهید. حداقل، از 0 به حداکثر RPS در یک پنجره زمانی 60 ثانیه شیب دهید. برای RPS بالاتر، ویندوزهای طولانی تر را ترجیح دهید.
در صورت امکان : از ارسال پیام در عرض 2 دقیقه از هر یک از علائم :00،:15،:30 و:45 خودداری کنید.
اجرای throttling سمت سرور برای نظارت و مدیریت جریان ترافیک به FCM.
در حالی که FCM تلاش می کند تا بسیار در دسترس باشد، گاهی اوقات برخی از درخواست ها به پایان می رسند یا با شکست مواجه می شوند. در حالی که دلایل متفاوت است، بهترین شیوه‌های زیر رفتار تلاش مجدد را بهینه می‌کنند تا پیام‌ها را در اسرع وقت ارسال کنند و در عین حال تأثیر آن بر ازدحام ترافیک را به حداقل می‌رسانند.
قبل از تلاش مجدد، برای درخواست‌های ارسال حداقل 10 ثانیه فاصله زمانی تعیین کنید. اکثر تماس‌های رویه از راه دور داخلی FCM از وقفه 10 ثانیه‌ای استفاده می‌کنند.
- برای خطاهای 400، 401، 403، 404: سقط کنید و دوباره امتحان نکنید.
- برای 429 خطا: پس از انتظار برای مدت زمان تعیین شده در سرصفحه سعی مجدد بعد از آن، دوباره امتحان کنید. اگر سرصفحه آزمون مجدد بعد از تنظیم نشده است، پیش‌فرض 60 ثانیه است.
- برای 500 خطا: با عقب نشینی نمایی دوباره امتحان کنید.
برای جلوگیری از تقویت مجدد، برای درخواست‌های مجدد، پس‌آف نمایی را با لرزش اجرا کنید. برای مثال، Firebase Admin SDK، عقب‌نشینی نمایی را پیاده‌سازی می‌کند.
در اینجا برخی از تنظیمات توصیه شده دیگر وجود دارد:
- حداقل فاصله: بلافاصله درخواست ناموفق را با FCM دوباره امتحان نکنید. قبل از اینکه درخواست ناموفق را دوباره امتحان کنید، حداقل 10 ثانیه صبر کنید.
- حداکثر فاصله: حداکثر فاصله زمانی را برای حذف درخواست هایی که دیگر به موقع نیستند، به جای تلاش مجدد به طور نامحدود تعیین کنید.
اگر درخواستی به طور مداوم با عقب نشینی نمایی دوباره امتحان شود و 60 دقیقه بعد همچنان ناموفق باشد، یا به اشتباه به عنوان یک خطای قابل امتحان مجدد طبقه بندی می شود، یا FCM در حال تجربه قطعی است که در آن تلاش های مجدد ممکن است به طور ناخواسته وضعیت را تشدید کند.
هنگام ایجاد تغییرات ترافیکی در مقیاس بزرگ، مانند افزایش ترافیک به FCM یا جابجایی ترافیک در مناطق یا شبکه‌ها، طراحی یک طرح بازگردانی/بازگشت و اجرای تغییرات تدریجی از کاربران، سرویس شما و FCM محافظت می‌کند.
- یک طرح عرضه انتظارات را برای ذینفعان همسو می کند. در شرایط خاص (که در زیر به آن پرداخته می شود)، ممکن است بخواهید طرح عرضه خود را از قبل با تیم FCM به اشتراک بگذارید تا از غافلگیری جلوگیری کنید.
- طرح بازگشت به شما اجازه می دهد تا موارد احتمالی را در نظر بگیرید و مکانیسم هایی را برای بازیابی سریع و ایمن از شکست های پیش بینی نشده آماده کنید.
- ایجاد تغییرات تدریجی دو جنبه دارد:
- گام‌های شیبدار: گام‌ها باید 1٪ -> 5٪ -> 10٪ -> 25٪ -> 50٪ -> 75٪ -> 100٪ یا بهتر باشد. " خیساندن " (رفتار سیستم تحت بار را مشاهده کنید) در هر مرحله به مدت 1 روز تا 1 هفته. این به شما امکان می دهد تا قبل از "گام به گام" بعدی، مشکلات احتمالی را شناسایی کنید.
- افزایش تدریجی ترافیک: هنگام برداشتن هر «گام» برای افزایش ترافیک، ترافیک را در بازه زمانی حداقل یک ساعته صاف کنید. این به زیرساخت تعادل بار FCM اجازه می‌دهد تا ترافیک جدید شما را به‌طور مناسب مقیاس‌بندی کند و در عین حال پتانسیل کانون‌ها و تراکم را به حداقل برساند.
در اینجا یک سناریوی فرضی برای انتقال 500000 RPS در سطح جهانی از API FCM Legacy HTTP به API FCM HTTP v1 آمده است:
| هفته | مرحله | استراتژی افزایش تدریجی |
|---|---|---|
| 0 | افزایش 1 درصدی | به آرامی از 0 تا 5000 RPS به FCM HTTP v1 در طول یک ساعت افزایش دهید. |
| 1 | افزایش 5 درصدی | به آرامی از 5000 به 25000 RPS در مدت 2 ساعت افزایش دهید. |
| 2 | افزایش 10 درصدی | افزایش هموار از 25000 تا 50000 RPS در مدت 2 ساعت |
| 3 | افزایش 25 درصدی | افزایش سرعت از 50000 به 125000 RPS در مدت 3 ساعت |
| 4 | افزایش 50 درصدی | افزایش سرعت از 125000 به 250000 RPS در مدت 6 ساعت |
| 5 | افزایش 75 درصدی | افزایش سرعت از 250000 به 375000 RPS در مدت 6 ساعت |
| 6 | 100% افزایش | افزایش سرعت از 375000 به 500000 RPS در مدت 6 ساعت |
طرح بازگشتی فرضی:
- اگر تأخیر 95 درصدی به بیش از 500 میلی ثانیه افزایش یابد یا اگر نسبت خطا برای بیش از یک ساعت در هر مرحله از 1٪ بیشتر شود، از پیکربندی پویا استفاده کنید تا فوراً به مرحله قبل برگردید.
- بازگشت به مراحل قبلی را ادامه دهید تا زمان تاخیر و نسبت خطا به سطوح اسمی بازگردد.
در صورت اعمال هر یک از موارد زیر از طریق پشتیبانی Firebase با FCM تماس بگیرید:
- سهمیه های پیش فرض دیگر مورد استفاده شما را برآورده نمی کند
- شما در حال تغییر الگوهای ارسال خود در یک پنجره 3 ماهه در مقیاس 100000 RPS در سطح جهانی یا 30000 RPS در سطح قاره هستید.