Niezależnie od tego, czy rozwijasz działającą aplikację, czy już korzystasz z usługi obsługującej 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 pomogą Ci uniknąć negatywnych skutków, gdy trzeba będzie wysyłać duże ilości wiadomości.
Najważniejsze terminy i koncepcje
Żądanie wiadomości: żądanie wiadomości z FCM używane zamiennie ze słowami „żądanie”, „wiadomość” i „zapytanie”.
Żądania na sekundę (RPS): wskaźnik opisujący odsetek żądań przychodzących do FCM używany zamiennie z liczbą zapytań na sekundę (QPS).
Tokeny limitu, zasobniki tokenów i uzupełnienia: podczas wysyłania wiadomości przez interfejs FCM HTTP v1 API każde żądanie wykorzystuje przydzielony token limitu w określonym przedziale czasu. Zasobnik tokenów wypełnia cały przedział czasu po upływie określonego czasu. Na przykład: interfejs API HTTP v1 przydziela 600 tys. tokenów limitu na każdy 1-minutowy zasobnik z tokenami, który zostaje w pełni zapełniony pod koniec każdego jednominutowego okresu.
Ograniczanie wykorzystania po stronie serwera: gdy natężenie ruchu przekracza pojemność usługi FCM, żądania wykraczające poza możliwości obsługi są odrzucane. Odpowiedzi na błędy (429) z nagłówkami retry-after mogą wskazywać, że należy odczekać określony czas, zanim spróbujesz ponownie.
Ograniczanie po stronie klienta: gdy klienci obserwują awarie żądań, duży czas oczekiwania lub błędy 429, powinni dobrowolnie ograniczać przepływ ruchu wychodzącego, aby uniknąć nadmiernego opóźnienia.
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.
Zakłócenia: unikanie ponawiania żądań w dokładnych odstępach czasu. Zakłócenia różnicują opóźnienia w ponownych próbach w losowy sposób i rozkładają je równomiernie 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: gdy nieudane żądania są ponawiane bez wykładniczego ponowienia i zakłóceń, często kumulują się i zwiększają bieżące obciążenie ruchu, potencjalnie „wzmacniając” i pogarszając problemy związane z korkowaniem 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 duży ruch?
Istnieje kilka różnych typów nagłych wzrostów ruchu.
Gwałtowny wzrost w ciągu godziny: w ciągu pierwszych 30 sekund do 2 minut każdej godziny w FCM ruch jest ponad 2 razy większy. Podobne, choć mniejsze, skoki są też zauważalne w godzinach 00:15, 00:30, 00:45.
Wzmacnianie ponawiania prób: ponawianie nieudanych lub przekraczających limit czasu żądań bez wykładniczego ponowienia może gromadzić się w powtarzających się falach ruchu poza dotychczasowymi strumieniami 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.
Wykorzystanie tokenów limitu z wyprzedzeniem: wykorzystanie wszystkich tokenów limitów na początku limitów zamiast równomiernego rozłożenia żądań między okna limitów spowoduje powstawanie oscylacjach, które są trudne i kosztowne w równoważeniu obciążenia.
Wydarzenia specjalne: zwiększony ruch w okresie świątecznym (sylwester) lub podczas wydarzeń sportowych (mistrzostwa świata w piłce nożnej
Wyeliminuj gwałtowne skoki ruchu, „wygładzając krzywą”.
W tej sekcji opisujemy strategie łagodzenia gwałtownych wzrostów natężenia ruchu tam, gdzie jest to możliwe, czyli strategie „wygładzania krzywej”.
Używaj FCM tylko w odpowiednich przypadkach użycia.
W niektórych przypadkach przesyłanie powiadomień przez FCM nie jest konieczne lub odpowiednie.
Na przykład w przypadku powiadomień o wydarzeniach w kalendarzu możesz zaplanować zadanie lokalne w aplikacji, aby wyświetlało powiadomienie o odpowiednich porach, zamiast wysyłać je z serwera aplikacji. Wiadomości w FCM możesz ograniczać do synchronizacji kalendarza.
Unikaj skoków
Jednym ze skalowania antywzorców jest wysyłanie powiadomień FCM tak szybko, jak pozwala na to system, 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 wzorzec dostępu powoduje problemy z równoważeniem obciążenia w FCM i systemach zależnych. Stopniowe zwiększanie ruchu. Minimalny wzrost powinien wynosić od 0 do maksymalnej liczby żądań na sekundę w 60-sekundowym przedziale czasu. Preferuj dłuższe przedziały czasu, aby uzyskać wyższą liczbę żądań na sekundę.
Unikaj korków działających bez przerwy
W miarę możliwości: unikaj wysyłania wiadomości w ciągu 2 minut od każdej wartości :00, :15, :30 i 45 minuty.
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 stara się zapewnić wysoką dostępność, niektóre żądania mogą czasami zostać przerwane lub mogą się nie powieść. Przyczyny są różne, ale poniższe sprawdzone metody optymalizują ponawianie prób dostarczenia wiadomości tak szybko, jak to możliwe, minimalizując jednocześnie wpływ na natężenie ruchu.
Czasy oczekiwania
Zanim spróbujesz ponownie, ustaw co najmniej 10-sekundowy czas oczekiwania dla żądań wysyłania. 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, odczekując przez czas określony w nagłówku Ponów. 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ąć wzmacniania ponownych prób, zaimplementuj wykładniczy czas ponawiania z zakłóceniami przy ponawianiu żądań. Na przykład pakiet Firebase Admin SDK implementuje wykładniczy 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 i po 60 minutach nadal się nie udaje, oznacza to, że jest błędnie klasyfikowane jako błąd, który można ponawiać, lub występuje przerwa w działaniu usługi FCM, w wyniku której kolejne próby nasilają tę sytuację.
tworzyć plany wdrażania i przywracania oraz wprowadzać stopniowe zmiany;
Gdy wprowadzasz zmiany w ruchu na dużą skalę, np. zwiększasz ruch w FCM lub przenosisz ruch między regionami bądź sieciami, zaplanujesz plan wdrażania/przywracania i wprowadzasz stopniowe zmiany, ochronisz swoich użytkowników, Twoją usługę 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:
- Kroki „stopniowe”: powinny wynosić 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% lub większe. „Uczęszczanie” (obserwuj zachowanie systemu przy obciążeniu) po każdym kroku przez okres od 1 dnia do tygodnia. Pozwoli Ci to wykryć potencjalne problemy, zanim wykonasz kolejny krok.
- Stopniowe zwiększanie natężenia ruchu: Podczas robienia kroków w celu zwiększenia natężenia ruchu wygładź go w ciągu co najmniej godziny. 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 globalnej migracji 500 tys. żądań na sekundę ze starszej wersji interfejsu API HTTP FCM do interfejsu FCM HTTP v1 API:
| 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 przez zespół pomocy Firebase, jeśli występuje którakolwiek z tych sytuacji:
- Domyślne limity nie są już zgodne z Twoim przypadkiem użycia
- Zmieniasz wzorce wysyłania w okresie 3 miesięcy na 100 tys. żądań na sekundę (globalnie) lub 30 000 żądań na sekundę (w kraju kontynentalnym).