Niezależnie od tego, czy rozwijasz działającą aplikację, czy już prowadzisz usługę obsługującą duży ruch, możesz skorzystać ze statystyk i zaleceń zawartych w tym przewodniku, które pomogą Ci płynnie skalować rozwiązania za pomocą FCM. Te koncepcje i metody mogą pomóc Ci uniknąć negatywnych skutków, gdy musisz wysyłać duże ilości wiadomości.
Najważniejsze terminy i koncepcje
Prośba o wiadomość: prośba o wiadomość FCM; używana zamiennie z terminami „prośba”, „wiadomość” lub „zapytanie”.
Żądania na sekundę (RPS): dane opisujące częstotliwość przychodzących żądań do FCM; używane zamiennie z danymi „Zapytania na sekundę (QPS)”.
Tokeny limitu, zbiory tokenów i ich uzupełnianie: podczas wysyłania wiadomości za pomocą interfejsu FCM HTTP w wersji 1 każde żądanie zużywa przydzielony token limitu w danym oknie czasowym. Okno to, nazywane pojemnikiem na tokeny, napełnia się do pełna pod koniec okna czasowego. Na przykład interfejs HTTP w wersji 1 przydziela 600 tys. tokenów limitu na każdy 1-minutowy koszyk tokenów, który napełnia się do pełna na koniec każdego 1-minutowego okna.
Ograniczanie na serwerze: gdy natężenie ruchu przekracza pojemność usługi FCM, żądania przekraczające pojemność serwera są odrzucane, aby ograniczyć napływ danych. Odpowiedzi na błędy (429) z nagłówkami retry-after mogą wskazywać, że należy odczekać określony czas, zanim spróbujesz ponownie.
Ograniczanie przepustowości po stronie klienta: gdy klienci odnotowują błędy 429, błędy związane z długim czasem oczekiwania lub błędy dotyczące żądań, powinni dobrowolnie ograniczyć przepustowość odpływu, aby uniknąć nasilenia zatorów.
Wykładniczy czas do ponowienia: w przypadku ponawiania błędów dodaj stopniowo zwiększające się opóźnienia. Na przykład: 1, 2, 4, 8, 16, 32.
Jitter: unikanie ponownego próbowania żądań w dokładnych odstępach. W przypadku jitteringu zmieniasz opóźnienia prób ponownego połączenia za pomocą procesu losowego, aby rozłożyć je równomiernie w czasie (np. 0,9 s, 2,3 s, 4,1 s, 8,5 s, 17,9 s, 34,7 s).
Ponowne próby: gdy nieudane żądania są powtarzane bez stosowania wzrastającego czasu do ponowienia lub ditheringu, często kumulują się i dodają do bieżącego obciążenia ruchu, co może „wzmacniać” i pogłębiać problemy z korkiem w ruchu.
Problem: nagłe wzrosty natężenia ruchu
FCM przetwarza miliony żądań na sekundę (RPS). Nagłe skoki ruchu i problemy z opóźnieniami powodują największe przerwy w ruchu w systemie.
Co to jest ruch o charakterze skumulowanym?
Istnieje kilka różnych typów nagłych wzrostów ruchu.
Szczyty godzinne: w pierwszych 30 sekundach do 2 minut każdej godziny FCM otrzymuje ponad dwukrotnie więcej ruchu niż w pozostałym czasie. Podobne, choć mniejsze, skoki są też zauważalne w godzinach 00:15, 00:30, 00:45.
Ponowne próby z wzmocnieniem: powtarzanie nieudanych żądań lub żądań, które osiągnęły limit czasu, bez zwrotnego wykładniczego może prowadzić do powtarzających się fal ruchu na szczytach dotychczasowych szczytów ruchu.
Nagłe zmiany wzorców ruchu: kierowanie nowego ruchu do FCM lub przenoszenie ruchu do FCM w różnych regionach bez stosowania czynników wygładzających, takich jak stopniowe przyspieszanie, może powodować skoki.
Front-loading tokenów limitu: wykorzystanie wszystkich tokenów limitu na początku okresu limitu zamiast równomiernego rozłożenia żądań w okresie limitu spowoduje wahania, które są trudne i drogie do zrównoważenia.
Wydarzenia specjalne: gwałtowne wzrosty ruchu w okresie świątecznym (sylwester) lub podczas wydarzeń sportowych (Mistrzostwa Świata w piłce nożnej FIFA).
Rozwiązywanie problemów z nagłymi wzrostami ruchu przez „spłaszczenie krzywej”.
W tej sekcji opisujemy strategie łagodzenia gwałtownych skoków natężenia ruchu tam, gdzie jest to możliwe, czyli strategie „wygładzania krzywej”.
Używaj FCM tylko w odpowiednich przypadkach.
W niektórych przypadkach przesyłanie powiadomień przez FCM nie jest konieczne lub odpowiednie.
Na przykład w przypadku powiadomień o wydarzeniu w kalendarzu możesz zaplanować lokalne zadanie w aplikacji, aby wyświetlało powiadomienie w odpowiednich momentach, zamiast wysyłać je z serwera aplikacji. Ograniczanie wiadomości FCM do synchronizacji z kalendarzem.
Unikaj nagłych wzrostów
Jednym ze sposobów na ograniczenie skalowania jest wysyłanie powiadomień FCM tak szybko, jak tylko systemy na to pozwalają, zamiast stosowania ograniczania przepustowości po stronie serwera. Zastanów się nad tymi kwestiami:
- Czy wszyscy Twoi klienci muszą otrzymać to samo powiadomienie w ciągu minuty? Czy 5-minutowy przedział dostawy nadal odpowiada Twoim potrzebom biznesowym?
- Czy Twoi klienci mogą być podzieleni na segmenty według priorytetu, aby wygładzić wzrosty?
- Czy powiadomienia można zaplanować z wyprzedzeniem?
W miarę możliwości: unikaj strategii, które powodują natychmiastowe wyczerpanie limitu wysyłania FCM, a następnie powtarzanie tego samego schematu, gdy tylko pula tokenów zostanie uzupełniona. Taki wzór dostępu powoduje problemy z balansem obciążenia w przypadku FCM i systemów, na których ono się opiera. Zwiększaj ruch stopniowo. Minimalnie zwiększaj liczbę żądań na sekundę od 0 do maksymalnej wartości w oknie czasowym 60 sekund. Wybieraj dłuższe okna, aby zwiększyć RPS.
Unikaj korków w godzinach szczytu.
W miarę możliwości: unikaj wysyłania wiadomości w ciągu 2 minut od każdej godziny, 15, 30 i 45 minut.
Wdrażanie ograniczania przepustowości po stronie serwera
Wdróż ograniczanie po stronie serwera, aby monitorować przepływ ruchu do FCM i nim zarządzać.
Obsługa ponawiania prób
Chociaż usługa FCM dąży do zapewnienia wysokiej dostępności, czasami niektóre żądania mogą się nie powieść lub przekroczyć limit czasu. Poniżej znajdziesz sprawdzone metody optymalizacji zachowania ponownego próbowania, które umożliwiają jak najszybsze dostarczanie wiadomości przy jednoczesnym minimalizowaniu wpływu na natężenie ruchu.
Czasy oczekiwania
Zanim spróbujesz ponownie, ustaw co najmniej 10-sekundowy czas oczekiwania dla żądań wysyłania. Większość wywołań procedur zdalnych w FCM korzysta z czasu oczekiwania wynoszącego 10 sekund.
Błędy
- W przypadku błędów 400, 401, 403 i 404: przerwij i nie próbuj ponownie.
- W przypadku błędów 429: spróbuj ponownie po upływie czasu ustawionego w nagłówku retry-after. Jeśli nie ustawiono nagłówka „Ponów próbę po”, domyślną wartością będzie 60 sekund.
- W przypadku błędów 500: podejmij ponowne próby ze wzrastającym czasem do ponowienia.
Wykładniczy czas do ponowienia
Aby uniknąć wzmocnienia prób, w przypadku prób ponownych użyj wykładniczego zmniejszania częstotliwości z jitterem. Pakiet Firebase Admin SDK stosuje na przykład wykładniczy czas oczekiwania.
Oto kilka zalecanych ustawień:
- Minimalny interwał: nie próbuj ponownie od razu przesłać nieudanej prośby za pomocą FCM. Zanim ponownie wyślesz nieudane żądanie, odczekaj co najmniej 10 sekund.
- Maksymalny interwał: ustaw maksymalny interwał, po którym żądania, które nie są już aktualne, będą odrzucane zamiast nieskończonej liczby prób.
Jeśli żądanie jest stale powtarzane ze wzrastającym czasem do ponowienia i nadal nie udaje się go zrealizować po 60 minutach, oznacza to, że zostało ono nieprawidłowo zaklasyfikowane jako błąd, który można powtórzyć, lub że usługa FCM ma problemy, a powtarzanie prób może niepotrzebnie pogarszać sytuację.
tworzyć plany wdrażania i przywracania oraz wprowadzać zmiany stopniowo.
W przypadku wprowadzania dużych zmian w ruchu, takich jak zwiększanie ruchu w FCM lub przenoszenie ruchu między regionami lub sieciami, opracowanie planu wdrażania/cofania oraz wdrażanie zmian stopniowo zapewni ochronę użytkowników, usługi i FCM.
- Plan wdrożenia pozwala dostosować oczekiwania interesariuszy. W niektórych sytuacjach (omówionych poniżej) warto udostępnić zespół FCM plan wdrożenia z wyprzedzeniem, aby uniknąć niespodzianek.
- Plan wycofywania umożliwia uwzględnienie nieprzewidzianych sytuacji i przygotowanie mechanizmów do szybkiego i bezpiecznego przywracania po nieoczekiwanych awariach.
- Stopniowe wprowadzanie zmian ma 2 aspekty:
- „Stopniowe” rampy: kroki powinny wynosić 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% lub więcej. „Soak” (obserwowanie zachowania systemu pod obciążeniem) na każdym kroku przez 1 dzień do 1 tygodnia. Pozwoli Ci to wykryć potencjalne problemy, zanim wykonasz kolejny krok.
- Stopniowe zwiększanie natężenia ruchu: podczas każdego „kroku” zwiększania natężenia ruchu wygładzaj ruch w ciągu co najmniej godziny. Dzięki temu infrastruktura równoważenia obciążenia FCM może odpowiednio skalować nowy ruch, minimalizując przy tym potencjalne wąskie gardła i korki.
Oto hipotetyczny scenariusz migracji 500 tys. RPS na całym świecie z interfejsu FCM Legacy HTTP API na interfejs FCM HTTP w wersji 1:
| Tydzień | Step | Stopniowe zwiększanie udziału |
|---|---|---|
| 0 | 1% optymalizacji | W ciągu godziny stopniowo zwiększaj liczbę RPS-ów z 0 do 5000,aż dojdzie do usługi FCM HTTP w wersji 1. |
| 1 | 5% zwiększenia wyświetleń | Płynne włączanie od 5000 do 25 000 żądań na sekundę w ciągu 2 godzin. |
| 2 | 10% | stopniowe zwiększanie liczby RPS z 25 tys. do 50 tys. w ciągu 2 godzin; |
| 3 | Wzrost na poziomie 25% | Przyspieszanie z 50 tys. do 125 tys. RPS w ciągu 3 godzin |
| 4 | 50% zwiększenia wyświetlania | Zwiększenie od 125 tys. do 250 tys. żądań na sekundę w ciągu 6 godzin |
| 5 | 75% optymalizacji | Zwiększenie z 250 tys. do 375 tys. żądań na sekundę w ciągu 6 godzin |
| 6 | 100% zwiększenia wyświetlania | Zwiększenie z 375 tys. do 500 tys. żądań na sekundę w ciągu 6 godzin |
Hipotetyczny plan przywrócenia:
- Jeśli czas oczekiwania w 95. procencie przypadków przekroczy 500 ms lub jeśli stosunek błędów przekroczy 1% przez ponad godzinę na dowolnym etapie, użyj konfiguracji dynamicznej, aby natychmiast wrócić do poprzedniego kroku.
- Kontynuuj cofanie do wcześniejszych kroków, aż czas oczekiwania i odsetek błędów powrócą do nominalnych wartości.
Kiedy kontaktować się z FCM
Skontaktuj się z komunikacją w chmurze Firebase za pomocą zespołu pomocy Firebase, jeśli wystąpi któryś z tych problemów:
- Domyślne limity nie spełniają już Twoich potrzeb
- zmieniasz wzorce wysyłania w ciągu 3 miesięcy na skalę 100 tys. RPS na całym świecie lub 30 tys. RPS na kontynencie.