Przejdź do treści 
Zadania asynchroniczne PHP rozwiązują typowe wąskie gardła, gdy zadania cron powodują szczytowe obciążenia, długi czas działania i brak przejrzystości. Pokażę, jak to zrobić. asynchroniczny PHP za pomocą kolejek i pracowników odciąża żądania sieciowe, skaluje obciążenia i łagodzi awarie bez frustracji.
Punkty centralne
Na początek podsumuję najważniejsze idee, na których opieram się w tym artykule i które stosuję w praktyce na co dzień. Podstawy
- Odsprzęganie żądania i zadania: żądania internetowe pozostają szybkie, zadania działają w tle.
- Skalowanie O pulach pracowników: więcej instancji, mniej czasu oczekiwania.
- niezawodność przez ponowne próby: ponowne uruchomienie nieudanych zadań.
- Przejrzystość Monitorowanie: długość kolejki, czasy realizacji, wskaźniki błędów w zasięgu wzroku.
- Separacja według obciążenia: krótkie, domyślne, długie z odpowiednimi limitami.
Dlaczego zadania cron nie są już wystarczające
Zadanie cron uruchamia się ściśle według godziny, a nie według rzeczywistego czasu. Wydarzenie. Gdy tylko użytkownik coś uruchomi, chcę natychmiast zareagować, zamiast czekać do następnej pełnej minuty. Wiele równoczesnych uruchomień cron powoduje szczytowe obciążenie, które na krótko przeciąża bazę danych, procesor i operacje wejścia/wyjścia. Równoległość pozostaje ograniczona i trudno mi jest odwzorować precyzyjne priorytety. Dzięki kolejkom mogę natychmiast przesuwać zadania do kolejki, uruchamiać kilka procesów równolegle i utrzymywać ciągłość działania interfejsu internetowego. responsywny. Użytkownicy WordPressa mogą dodatkowo skorzystać, jeśli Zrozumieć WP-Cron i chcesz skonfigurować go w sposób przejrzysty, aby planowanie sterowane czasowo trafiało niezawodnie do kolejki.
Przetwarzanie asynchroniczne: krótkie wyjaśnienie pojęcia „job–queue–worker”
Kosztowne zadania umieszczam w przejrzystym Praca, który opisuje, co należy zrobić, wraz z odniesieniami do danych. Zadanie to trafia do kolejki, którą wykorzystuję jako bufor na wypadek szczytowego obciążenia i która obsługuje wielu konsumentów. Pracownik to trwały proces, który odczytuje zadania z kolejki, wykonuje je i potwierdza wynik. Jeśli pracownik ulegnie awarii, zadanie pozostaje w kolejce i może zostać przetworzone później przez inną instancję. To luźne połączenie sprawia, że aplikacja jako całość odporny na błędy i zapewnia stały czas odpowiedzi w interfejsie użytkownika.
Jak działają kolejki i procesy robocze w środowisku PHP
W PHP definiuję zadanie jako prostą klasę lub jako serializowalną ładowność za pomocą modułu obsługi. Kolejką może być tabela bazy danych, Redis, RabbitMQ, SQS lub Kafka, w zależności od wielkości i wymagań dotyczących opóźnień. Procesy robocze działają niezależnie, często jako usługi nadzorcze, systemowe lub kontenerowe, i stale pobierają zadania. Używam mechanizmów ACK/NACK, aby wyraźnie sygnalizować pomyślne i nieudane przetworzenie. Ważne jest, aby Przepustowość dostosować pracownika do oczekiwanej ilości zadań, w przeciwnym razie kolejka będzie rosnąć w niekontrolowany sposób.
Pracownicy PHP w środowiskach hostingowych: równowaga zamiast wąskiego gardła
Zbyt mała liczba procesów PHP powoduje zatory, zbyt duża liczba procesów obciąża procesor i pamięć RAM, spowalniając wszystko, łącznie z Żądania internetowe. Planuję liczbę pracowników i współbieżność osobno dla każdej kolejki, aby krótkie zadania nie utknęły w długich raportach. Ponadto ustawiam limity pamięci i regularne restarty, aby wychwycić wycieki. Jeśli nie masz pewności co do limitów, rdzeni procesora i współbieżności, przeczytaj mój zwięzły Poradnik dotyczący pracowników PHP z typowymi strategiami równowagi. Ta równowaga ostatecznie zapewnia niezbędną Możliwość planowania dla wzrostu i równomiernych czasów odpowiedzi.
Limity czasu, ponowne próby i idempotencja: zapewnienie niezawodnego przetwarzania
Każdej pracy przypisuję Limit czasu, aby żaden pracownik nie był w nieskończoność zajęty wadliwymi zadaniami. Broker otrzymuje limit czasu widoczności, który jest nieco większy niż maksymalny czas trwania zadania, aby zadanie nie pojawiło się dwukrotnie. Ponieważ wiele systemów korzysta z dostarczania „przynajmniej raz“, wdrażam idempotentne procedury obsługi: podwójne wywołania nie powodują podwójnych wiadomości e-mail lub płatności. Ponowne próby wyposażam w funkcję backoff, aby nie przeciążać zewnętrznych interfejsów API. W ten sposób utrzymuję Wskaźnik błędów niski i potrafi dokładnie zdiagnozować problemy.
Rozdzielanie obciążeń: krótkie, domyślne i długie
Tworzę osobne kolejki dla zadań krótkich, średnich i długich, aby eksport nie blokował dziesięciu powiadomień i Użytkownik każda kolejka otrzymuje własne pule pracowników z odpowiednimi limitami czasu działania, współbieżności i pamięci. Krótkie zadania korzystają z większej równoległości i ścisłych limitów czasowych, podczas gdy długie procesy otrzymują więcej mocy obliczeniowej procesora i dłuższy czas działania. Priorytety kontroluję poprzez rozdzielenie pracowników między kolejki. To wyraźne rozdzielenie zapewnia przewidywalność. Opóźnienia w całym systemie.
Porównanie opcji kolejki: kiedy który system jest odpowiedni
Celowo wybieram kolejkę pod kątem opóźnień, trwałości, działania i ścieżki rozwoju, aby później nie musieć ponosić wysokich kosztów migracji i Skalowanie pozostaje pod kontrolą.
| System kolejki | Użycie | Opóźnienie | Cechy charakterystyczne |
|---|---|---|---|
| Baza danych (MySQL/PostgreSQL) | Małe konfiguracje, łatwy start | Średni | Łatwa obsługa, ale szybka wąskie gardło przy dużym obciążeniu |
| Redis | Małe i średnie obciążenia | Niski | Bardzo szybki w pamięci RAM, wymaga przejrzystości Konfiguracja za niezawodność |
| RabbitMQ / Amazon SQS / Kafka | Duże, rozproszone systemy | Niski do średniego | Bogate funkcje, dobra Skalowanie, większe koszty operacyjne |
Właściwe wykorzystanie Redis – unikanie typowych przeszkód
Redis wydaje się działać błyskawicznie, ale nieprawidłowe ustawienia lub nieodpowiednie struktury danych prowadzą do dziwnych Czas oczekiwania. Zwracam uwagę na strategie AOF/RDB, opóźnienia sieciowe, zbyt duże ładunki i polecenia blokujące. Ponadto oddzielam buforowanie i obciążenia kolejki, aby szczyty buforowania nie spowalniały pobierania zadań. Kompaktową listę kontrolną błędnych konfiguracji można znaleźć w tym przewodniku. Błędna konfiguracja Redis. Kto dokonuje precyzyjnej regulacji, otrzymuje szybką i niezawodną kolejka do wielu zastosowań.
Monitorowanie i skalowanie w praktyce
Mierzę długość kolejki w czasie, ponieważ rosnące zaległości sygnalizują brak zasobów roboczych. Średni czas trwania zadania pomaga realistycznie ustawić limity czasu i zaplanować wydajność. Wskaźniki błędów i liczba ponownych prób pokazują mi, kiedy zewnętrzne zależności lub ścieżki kodu są niestabilne. W kontenerach automatycznie skaluję zasoby robocze na podstawie metryk procesora i kolejki, podczas gdy mniejsze konfiguracje radzą sobie z prostymi skryptami. Widoczność pozostaje kluczowa, ponieważ tylko liczby zapewniają solidną podstawę do podejmowania decyzji. Decyzje włączyć.
Cron plus Queue: jasny podział ról zamiast konkurencji
Używam Cron jako zegara, który planuje zadania sterowane czasowo, podczas gdy pracownicy wykonują rzeczywistą pracę. Praca przejmują. Dzięki temu nie powstają ogromne szczyty obciążenia w pełnej minucie, a spontaniczne zdarzenia są natychmiastowo reagowane za pomocą zadań w kolejce. Powtarzające się raporty zbiorcze planuję za pomocą Cron, ale każdy szczegół raportu jest przetwarzany przez pracownika. W przypadku konfiguracji WordPress stosuję się do wytycznych zawartych w „Zrozumieć WP-Cron“, aby planowanie pozostało spójne. Dzięki temu zachowuję porządek w harmonogramie i zapewniam sobie Elastyczność w wykonaniu.
Nowoczesne środowiska uruchomieniowe PHP: RoadRunner i FrankenPHP w połączeniu z kolejkami
Trwałe procesy robocze oszczędzają nakłady związane z uruchamianiem, utrzymują otwarte połączenia i zmniejszają Opóźnienie. RoadRunner i FrankenPHP stawiają na długotrwałe procesy, pule pracowników i pamięć współdzieloną, co znacznie podnosi wydajność pod obciążeniem. W połączeniu z kolejkami zachowuję stałą przepustowość i korzystam z ponownie wykorzystywanych zasobów. Często oddzielam obsługę HTTP i konsumentów kolejki do osobnych pul, aby ruch internetowy i zadania w tle nie zakłócały się nawzajem. Kto tak pracuje, tworzy spokojną Wydajność nawet przy silnych wahaniach popytu.
Bezpieczeństwo: oszczędne i szyfrowane przetwarzanie danych
Nigdy nie umieszczam danych osobowych bezpośrednio w ładunku, a jedynie identyfikatory, które później ponownie ładuję, aby Ochrona danych Wszystkie połączenia z brokerem są szyfrowane, a ja korzystam z szyfrowania spoczynkowego, o ile usługa to oferuje. Producent i konsument otrzymują oddzielne uprawnienia z minimalnymi prawami. Regularnie zmieniam dane dostępowe i nie umieszczam tajnych informacji w logach i metrykach. Takie podejście zmniejsza powierzchnię ataku i chroni Poufność informacji wrażliwych.
Praktyczne scenariusze zastosowań dla Async-PHP
Nie wysyłam już e-maili w Webrequest, ale umieszczam je jako zadania, aby użytkownicy nie musieli czekać na Wysyłka czekać. W przypadku przetwarzania multimediów przesyłam zdjęcia, natychmiast udzielam odpowiedzi, a miniatury generuję później, co znacznie usprawnia proces przesyłania. Raporty zawierające wiele rekordów danych uruchamiam asynchronicznie i udostępniam wyniki do pobrania, gdy tylko pracownik zakończy pracę. W przypadku integracji z systemami płatności, CRM lub marketingowymi odłączam wywołania API, aby spokojnie amortyzować przekroczenia limitów czasu i sporadyczne awarie. Rozgrzewanie pamięci podręcznej i aktualizacje indeksu wyszukiwania przenoszę za kulisy, aby UI pozostaje szybki.
Projektowanie zadań i przepływ danych: ładunki, wersjonowanie i klucze idempotencji
Staramy się, aby ładunki były jak najmniejsze i zapisujemy tylko odniesienia: jeden ID, typ, wersję oraz klucz korelacji lub idempotencji. Wersja służy do oznaczenia schematu ładunku i umożliwia spokojną dalszą pracę nad handlerem, podczas gdy stare zadania są nadal przetwarzane. Klucz idempotencji zapobiega powstawaniu podwójnych efektów ubocznych: jest on zapisywany w pamięci danych podczas uruchomienia i porównywany podczas powtórzeń, aby nie powstała druga wiadomość e-mail lub rezerwacja. W przypadku złożonych zadań dzielę zadania na małe, jasno zdefiniowane kroki (polecenia) zamiast umieszczać całe przepływy pracy w jednym zadaniu – dzięki temu możliwe jest ponowne próby i obsługa błędów. ukierunkowany chwycić.
W przypadku aktualizacji korzystam z Wzór skrzynki nadawczej: Zmiany są zapisywane w tabeli skrzynki nadawczej w ramach transakcji bazy danych, a następnie publikowane przez pracownika w rzeczywistej kolejce. W ten sposób unikam niespójności między danymi aplikacji a wysłanymi zadaniami i otrzymuję solidną „przynajmniej raz“Dostarczanie z dokładnie określonymi efektami ubocznymi.
Obrazy błędów, DLQ i „Poison Messages“
Nie każdy błąd jest przejściowy. Dokonuję wyraźnego rozróżnienia między problemami, które można rozwiązać poprzez Próby rozwiązać (sieć, limity szybkości) i błędy końcowe (brakujące dane, walidacje). W przypadku tych ostatnich tworzę Kolejka martwych listów (DLQ): po ograniczonej liczbie ponownych prób zadanie trafia tam. W DLQ zapisuję przyczynę, fragment stacktrace, liczbę ponownych prób i link do odpowiednich podmiotów. Dzięki temu mogę podjąć konkretną decyzję: ręcznie ponownie uruchomić, poprawić dane lub naprawić handler. „Poison Messages“ (zadania, które ulegają powtarzalnym awariom) rozpoznaję po natychmiastowym niepowodzeniu startu i blokuję je na wczesnym etapie, aby nie spowalniały całej puli.
Łagodne wyłączanie, wdrażanie i restartowanie
Podczas wdrażania trzymam się Łagodne wyłączanie: Proces przetwarza bieżące zadania do końca, ale nie przyjmuje nowych. W tym celu przechwytuję SIGTERM, ustawiam status „draining“ i w razie potrzeby przedłużam widoczność (Visibility Timeout), aby broker nie przydzielił zadania innemu pracownikowi. W konfiguracjach kontenerowych planuję długi okres terminacji, dostosowany do maksymalnego czasu trwania zadania. Ograniczam restartowanie do małych partii, aby Pojemność nie ulegnie awarii. Dodatkowo ustawiam Heartbeats/Healthchecks, które zapewniają, że tylko sprawne moduły robocze wykonują zadania.
Batching, limity szybkości i przeciwciśnienie
Wiele drobnych operacji łączę, jeśli ma to sens, w Partie razem: pracownik ładuje 100 identyfikatorów, przetwarza je za jednym razem, zmniejszając w ten sposób obciążenie związane z opóźnieniami sieciowymi i nawiązywaniem połączeń. W przypadku zewnętrznych interfejsów API przestrzegam limitów szybkości i kontroluję mechanizmy token bucket lub leaky bucket. częstotliwość zapytań. Jeśli wzrasta wskaźnik błędów lub opóźnienia, pracownik automatycznie zmniejsza równoległość (adaptacyjna współbieżność), aż sytuacja się ustabilizuje. Backpressure oznacza, że producenci ograniczają produkcję zadań, gdy długość kolejki przekracza określone wartości progowe – w ten sposób unikam lawin, które mogą przeciążyć system.
Priorytety, uczciwość i rozdzielenie klientów
Priorytetyzację realizuję nie tylko za pomocą poszczególnych kolejek priorytetowych, ale również za pomocą ważone Przydzielanie pracowników: pula pracuje w 70% „short“, w 20% „default“ i w 10% „long“, aby żadna kategoria nie została całkowicie pominięta. W konfiguracjach wielodostępnych izoluję krytycznych klientów za pomocą własnych kolejek lub dedykowanych pul pracowników, aby Hałaśliwi sąsiedzi . W przypadku raportów unikam sztywnych priorytetów, które powodują niekończące się opóźnienia długotrwałych zadań; zamiast tego planuję przedziały czasowe (np. w nocy) i ograniczam liczbę równoległych zadań wymagających dużej mocy obliczeniowej, aby platforma mogła pracować w ciągu dnia. snappy pozostaje.
Obserwowalność: ustrukturyzowane logi, korelacja i SLO
Loguję w sposób uporządkowany: identyfikator zadania, identyfikator korelacji, czas trwania, status, liczbę ponownych prób i ważne parametry. W ten sposób koreluję żądanie frontendu, zadanie w kolejce i historię pracownika. Na podstawie tych danych definiuję SLO: około 95% wszystkich zadań „short“ w ciągu 2 sekund, „default“ w ciągu 30 sekund, „long“ w ciągu 10 minut. Alerty uruchamiają się w przypadku rosnącego zaległości, wzrostu wskaźnika błędów, nietypowych czasów działania lub wzrostu DLQ. Runbooki opisują konkretne kroki: skalowanie, ograniczanie, ponowne uruchamianie, analiza DLQ. Tylko dzięki jasnym wskaźnikom mogę podejmować dobre decyzje. Decyzje dotyczące wydajności.
Rozwój i testy: lokalne, powtarzalne, niezawodne
W przypadku rozwoju lokalnego stosuję Fałszywa kolejka lub prawdziwą instancję w trybie Dev i uruchamiam Worker w tle, aby logi były natychmiast widoczne. Piszę testy integracyjne, które umieszczają zadanie w kolejce, wykonują Worker i sprawdzają oczekiwany wynik strony (np. zmianę w bazie danych). Symuluję testy obciążeniowe za pomocą wygenerowanych zadań i mierzę przepustowość, 95/99 percentyle i wskaźniki błędów. Ważne jest powtarzalne zasiewanie danych i deterministyczne procedury obsługi, aby testy pozostały stabilne. Wycieki pamięci są wykrywane w testach ciągłych; planuję okresowe restartowanie i monitoruję krzywa pamięci.
Zarządzanie zasobami: procesor kontra wejście/wyjście, pamięć i równoległość
Rozróżniam zadania obciążające procesor i zadania obciążające wejście/wyjście. Zadania intensywnie wykorzystujące procesor (np. transformacje obrazów) wyraźnie ograniczam pod względem równoległości i rezerwuję rdzenie. Zadania obciążające wejście/wyjście (sieć, baza danych) korzystają z większej współbieżności, o ile opóźnienia i błędy pozostają stabilne. W przypadku PHP stawiam na opcache, zwracam uwagę na połączenia wielokrotnego użytku (Persistent Connections) w trwałych workerach i wyraźnie zwalniam obiekty na końcu zadania, aby Fragmentacja . Twarde ograniczenie dla każdego zadania (pamięć/czas działania) zapobiega sytuacji, w której wartości odstające mają negatywny wpływ na całą pulę.
Stopniowa migracja: od zadania cron do podejścia „queue-first”
Migruję stopniowo: najpierw przenoszę niekrytyczne zadania związane z pocztą elektroniczną i powiadomieniami do kolejki. Następnie przetwarzanie multimediów i wywołania integracyjne, które często powodują przekroczenie limitu czasu. Istniejące zadania cron pozostają zegarem, ale przenoszą swoją pracę do kolejki. W następnym kroku dzielę obciążenia na krótkie/domyślne/długie i konsekwentnie je mierzę. Na koniec usuwam ciężką logikę cron, gdy tylko pracownicy zaczną działać stabilnie, i przechodzę na Sterowane zdarzeniami Punkty kolejkowania (np. „Użytkownik zarejestrował się“ → „Wyślij wiadomość powitalną“). W ten sposób zmniejsza się ryzyko, a zespół i infrastruktura w kontrolowany sposób dostosowują się do nowego schematu.
Zarządzanie i eksploatacja: zasady, limity i kontrola kosztów
Określam jasne zasady: maksymalny rozmiar ładunku, dopuszczalny czas działania, dozwolone cele zewnętrzne, limity na klienta i przedziały czasowe w ciągu dnia dla kosztownych zadań. Kontroluję koszty, skalując pule pracowników w nocy, grupując zadania wsadowe w godzinach poza szczytem i ustalając limity dla usług w chmurze, które Wartości odstające zapobiegać. W przypadku incydentów mam przygotowaną ścieżkę eskalacji: alarm DLQ → analiza → poprawka lub korekta danych → kontrolowane ponowne przetwarzanie. Dzięki tej dyscyplinie system pozostaje pod kontrolą – nawet jeśli się rozrasta.
Podsumowanie: Od zadania cron do skalowalnej architektury asynchronicznej
Rozwiązuję problemy związane z wydajnością, oddzielając powolne zadania od odpowiedzi sieciowej i przekazując je za pośrednictwem Pracownik przetwarzam. Kolejki buforują obciążenie, ustalają priorytety zadań i porządkują ponowne próby i obrazy błędów. Dzięki oddzielnym obciążeniom, czystym limitom czasu i idempotentnym handlerom system pozostaje przewidywalny. Hosting, limity pracowników i wybór brokera decyduję na podstawie rzeczywistych wskaźników, a nie intuicji. Kto wcześnie postawi na tę architekturę, otrzyma szybsze odpowiedzi, lepsze Skalowanie i znacznie większy spokój w codziennej pracy.
