Niezależnie od tego, czy rozwijasz działającą aplikację, czy masz już usługę obsługującą duży ruch, zawarte w tym przewodniku statystyki i rekomendacje dotyczące zwiększania skali z FCM. Te koncepcje i metody pomogą Ci uniknąć negatywnych ma znaczenie przy wysyłaniu dużych ilości wiadomości.
Najważniejsze terminy i koncepcje
Żądanie wiadomości: żądanie wiadomości z FCM. używany zamiennie z „żądaniem”, „message” lub „query”
Żądania na sekundę (RPS): wskaźnik opisujący współczynnik przychodzących zapytań do FCM; używana wymiennie z liczbą zapytań na sekundę (QPS).
Tokeny limitów, zasobniki tokenów i uzupełnianie: w przypadku wysyłania wiadomości do Interfejs API FCM HTTP w wersji 1 – każde żądanie zużywa przydzielony token limitu w danym czasie okno. Zasobnik tokenów wypełnia cały klucz na końcu przedział czasu. Na przykład: interfejs API HTTP w wersji 1 przydziela 600 tys. tokenów limitu 1-minutowy zasobnik na tokeny, który napełnia się pod koniec każdego jednominutowego okresu.
Ograniczanie po stronie serwera: gdy natężenie ruchu przekracza wartość określoną w usłudze FCM.
pojemności, żądania wykraczające poza możliwości obsługi są odrzucane w ruchu przychodzącym z ograniczeniem liczby żądań
przepływu danych. Odpowiedzi na błędy (429) z nagłówkami retry-after mogą być zwracane w celu wskazania
że musisz odczekać określony czas, zanim spróbujesz ponownie.
Ograniczanie po stronie klienta: gdy klienci obserwują błędy żądań, duże opóźnienia,
lub 429, powinny dobrowolnie ograniczać przepływ ruchu wychodzącego, aby uniknąć nasilenia
zatłoczenie.
Wykładniczy czas do ponowienia: Przy ponawianiu błędów dodaj stopniowo zwiększające się opóźnienia. Na przykład: 1 s, 2, 4, 8, 16, 32
Zakłócenia: unikanie ponawiania żądań w dokładnych odstępach czasu. Zakłócenia Możesz zmieniać opóźnienia ponawiania prób w losowym procesie, aby je równomiernie rozłożyć. w czasie (np. 0,9 s, 2,3 s, 4,1 s, 8,5 s, 17,9 s, 34,7 s).
Wzmacnianie ponawiania prób: w przypadku ponawiania nieudanych żądań bez zwiększania wykładniczego. powolne ponowienie/zakłócenia, często kumulują się i zwiększają obecne obciążenie ruchu, potencjalnie „wzmacniać” i rozwijaniem korków w ruchu drogowym.
Problem: nagłe wzrosty natężenia ruchu
FCM przetwarza miliony żądań na sekundę (RPS). Największy współtwórca przeciążenie systemu, problemy z opóźnieniami i przerwy w działaniu to zwiększony ruch.
Co to jest duży ruch?
Istnieje kilka różnych typów nagłych wzrostów ruchu.
Gwałtowny wzrost w ciągu godziny: przez pierwszych 30 dni w FCM odnotowuje ponad 2 razy większy ruch. od sekund do 2 minut z każdej godziny. Podobne, choć mniejsze, skoki zaobserwowane w oznaczeniach półgodziny i kwadransów (przykłady: 00:15, 00:30, 00:45).
Wzmacnianie ponownych prób: ponawianie nieudanych lub przekraczania limitu czasu żądań bez Wykładniczy czas do ponowienia może kumulują się w powtarzających się falach ukształtowanych nad istniejącymi granicami 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 i powodować gwałtowne skoki.
Wykorzystanie tokenów limitu z wyprzedzeniem: wyczerpanie wszystkich tokenów limitu na początku limitów zamiast równomiernie rozłożyć żądania między limit w oknach powodują drgania, które są trudne i kosztowne systemu równoważenia obciążenia.
Wydarzenia specjalne: nagłe zwiększenie ruchu w okresie świątecznym (sylwester) lub podczas wydarzeń sportowych (Puchar Świata w Piłce Nożnej).
Wyeliminuj gwałtowne skoki ruchu, „wygładzając krzywą”.
W tej sekcji znajdziesz strategie łagodzenia gwałtownych skoków natężenia ruchu, to strategie „wygładzania krzywej”.
FCM">Używaj narzędzia FCM tylko w odpowiednich przypadkach użycia
W niektórych przypadkach wykorzystanie FCM do wysyłania powiadomień niezbędne lub odpowiednie.
Na przykład w przypadku powiadomień o wydarzeniach w kalendarzu możesz zaplanować zadanie lokalne w wyświetlanie powiadomienia w odpowiednich momentach, zamiast wysyłania go z serwera aplikacji. Wiadomości w FCM możesz ograniczać do synchronizacji kalendarza.
Unikaj skoków
Antywzorcem może być na przykład wysyłanie powiadomień FCM tak szybko, jak systemy zezwalaj zamiast stosowania ograniczania po stronie serwera. Weź pod uwagę te kwestie:
- Czy wszyscy Twoi klienci muszą otrzymać to samo powiadomienie w ciągu minuty? Czy na przykład 5-minutowy okres dostawy wciąż odpowiada Twoim potrzebom biznesowym?
- Czy klientów można podzielić na segmenty według priorytetu, aby wygładzić nagły wzrost?
- Czy powiadomienia można zaplanować z wyprzedzeniem?
W miarę możliwości: unikaj strategii, które powodują natychmiastowe wyczerpanie limitu wysyłania w FCM, tylko powtórzenie wzorca, gdy tylko zasobnik z tokenami zostanie uzupełniony. Ten dostęp powoduje problemy z równoważeniem obciążenia w FCM i jego zależnościach zależnych systemów uczących się. Stopniowe zwiększanie ruchu. Minimalny wzrost z 0 do 0 maksymalną liczbę żądań na sekundę w 60-sekundowym przedziale czasu. Wolę dłuższe okna, tym więcej Żądania na sekundę.
Nie pracuj całodobowo ruch drogowy
W miarę możliwości: unikaj wysyłania wiadomości w ciągu 2 minut od każdego z w znakach :00, :15, :30 i :45 minut.
Wdrażanie ograniczania po stronie serwera
Wdróż ograniczanie po stronie serwera, aby monitorować przepływ ruchu do FCM i nim zarządzać.
Obsługa ponownych prób
Choć FCM wymaga dużej dostępności, czasami prośby mogą zostać przekroczone lub porażki. Przyczyny są różne, ale poniższe sprawdzone metody optymalizują ponowienie próby działania, aby dostarczać wiadomości tak szybko, jak to możliwe, przy minimalnym wpływie korki.
Czasy oczekiwania
Ustaw co najmniej 10-sekundowy czas oczekiwania dla żądań wysyłania przed ponawiam próbę. Większość wewnętrznych zdalnych wywołań procedury FCM ma 10-sekundowy czas oczekiwania.
Błędy
- Błędy 400, 401, 403 i 404: przerwij i nie ponawiaj próby.
- W przypadku błędów 429: spróbuj ponownie po odczekaniu czasu ustawionego w ustawieniu „Ponów próbę po” nagłówek. 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: ponów próbę ze wzrastającym czasem do ponowienia.
Wykładniczy czas do ponowienia
Aby uniknąć wzmocnienia ponownych prób, zaimplementuj wykładnicze i problemy z ponawianiem żądań. pakietu Firebase Admin SDK, implementuje wzrastający czas do ponowienia.
Oto kilka dodatkowych zalecanych ustawień:
- Minimalny odstęp: nie ponawiaj od razu ponownych prób w nieudanym żądaniu w FCM. Poczekaj co najmniej 10 sekund, zanim spróbujesz ponownie zrealizować nieudane żądanie.
- Maksymalny interwał: ustaw maksymalny odstęp czasu między żądaniami, które nie są już aktualne, zamiast ponawiać próby w nieskończoność.
Jeśli żądanie jest stale ponawiane ze wzrastającym czasem do ponowienia, a wciąż jest jeśli po 60 minutach wystąpi błąd, zostanie on błędnie sklasyfikowany jako błąd, który można ponawiać lub Wystąpiła przerwa w działaniu FCM, w wyniku której ponawianie próby może być nieumyślnie nasilające. zaistniałą sytuację.
tworzyć plany wdrażania i przywracania oraz wprowadzać stopniowe zmiany;
podczas wprowadzania zmian w ruchu na dużą skalę, takich jak zwiększenie ruchu w FCM lub przenoszenia ruchu między regionami lub sieciami, zaprojektowanie planu wdrożenia/przywrócenia; a wdrażanie stopniowych zmian zapewni ochronę Twoich użytkowników, usługi i FCM.
- Plan wdrażania uwzględnia oczekiwania zainteresowanych osób. W pewnych sytuacjach (opisanych poniżej) warto wcześniej udostępnić zespołowi FCM plan wdrożenia, aby uniknąć niespodzianek.
- Plan przywracania pozwala uwzględnić ewentualne okoliczności i przygotować mechanizmy, które umożliwią szybkie i bezpieczne przywracanie sprawności po niespodziewanych błędach.
- Stopniowe zmiany mają 2 aspekty:
- „Stopniowo” podwyższenia: kroki powinny wynosić 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% lub mniej. „Wesprzyj” (obserwuj zachowanie systemu podczas wczytywania) każdego kroku przez 1 dzień do 1 tygodnia. Pozwoli Ci to wykryć potencjalne problemy, zanim wykonasz kolejny krok.
- Stopniowe zwiększanie natężenia ruchu: podczas wykonywania każdego etapu zwiększyć natężenie ruchu, wygładź je na co najmniej godzinę. Dzięki temu infrastruktura równoważenia obciążenia FCM może odpowiednio skalować nowy ruch, minimalizując jednocześnie ryzyko wystąpienia hotspotów i zatorów.
Oto hipotetyczny scenariusz migracji 500 000 żądań na sekundę na całym świecie z Do interfejsu FCM HTTP v1 API – starsza wersja interfejsu API FCM:
| Tydzień | Step | Strategia stopniowego zwiększania skuteczności |
|---|---|---|
| 0 | 1% optymalizacji | Płynne włączanie od 0 do 5000 żądań na sekundę do FCM HTTP w wersji 1 w ciągu godziny. |
| 1 | 5% optymalizacji | Płynne włączanie od 5000 do 25 000 żądań na sekundę w ciągu 2 godzin. |
| 2 | 10-procentowy wzrost | Płynne włączanie od 25 000 do 50 000 żądań na sekundę w ciągu 2 godzin |
| 3 | Wzrost na poziomie 25% | Zwiększenie z 50 tys. do 125 tys. żądań na sekundę w ciągu 3 godzin |
| 4 | Wzrost na poziomie 50% | 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-procentowy wzrost | Zwiększenie z 375 tys. do 500 tys. żądań na sekundę w ciągu 6 godzin |
Hipotetyczny plan wycofania:
- Jeśli 95-percentyl czasu oczekiwania zwiększy się do ponad 500 ms lub jeśli współczynnik błędu przekroczy 1% przez ponad godzinę w dowolnym kroku, użyj konfiguracji dynamicznej, aby natychmiast wrócić do poprzedniego kroku.
- Kontynuuj przywracanie do wcześniejszych kroków, aż czas oczekiwania i współczynnik błędów wróci do wartości nominalnych.
Kiedy należy skontaktować się z FCM
Skontaktuj się z FCM, korzystając z pomocy Firebase. w którejkolwiek z tych sytuacji:
- Domyślne limity nie są już zgodne z Twoim przypadkiem użycia
- Zmieniasz wzorce wysyłania w ciągu 3 miesięcy na stronie 100 000 żądań na sekundę (na całym świecie) lub 30 000 żądań na sekundę (kontynent)