Vrijdagavond verschijnt in de winkel “bestelling bevestigd”. De bevestigingsmail is nooit weggegaan. Maandagochtend ontdekte ondersteuning een lege jobs-tabel aan de applicatiezijde, maar honderden vermeldingen in failed_jobs, allemaal gekoppeld aan een SMTP-time-out na de versie-upgrade van het weekend.
Dit scenario is banaal: de webinterface reageert snel omdat Laravel de taak met succes heeft verzonden, maar niemand heeft het verbruik of de storingen gecontroleerd. Wachtrijen zijn geen probleem als alles goed gaat. Ze worden zichtbaar wanneer een medewerker stopt, een slecht geconfigureerd stuurprogramma overschakelt naar 'synchronisatie', of een agressieve nieuwe poging een externe fout versterkt.
Stuurprogramma, verbinding en wat Laravel werkelijk draait
Een Laravel-taak is geen magie: het is een geserialiseerd bericht (klasse, payload, pogingen) opgeslagen in een backend – Redis, database, SQS, Beanstalkd. De worker (queue:work of Horizon) plaatst deze, instantieert de klasse, voert handle() uit en erkent of markeert vervolgens de mislukking.
| Bestuurder | Wanneer moet u het gebruiken | Frequente limiet |
|---|---|---|
opnieuw | Productie door meerdere medewerkers, lage latentie | Redis moet persistent zijn en worden gecontroleerd |
database | Klein volume, geen makelaar | Strijd over de zwaarbelaste 'banentafel' |
sqs | AWS Cloud, regionale ontkoppeling | Kosten en zichtbaarheid van te configureren DLQ's |
synchroniseren | Alleen lokaal testen | Inline-uitvoering — geen veerkracht |
Bij gedeelde hosting vermijdt beheerde Redis of een kleine VPS speciaal voor de makelaar de vermenging van webbelasting en taakverbruik. Documenteer op een enkele VPS wie de medewerker opnieuw opstart na een implementatie: een slecht herladen 'supervisor' laat de wachtrij groeien zonder zichtbare fouten aan de HTTP-kant.
Een site die binnen 200 ms reageert, kan functioneel defect zijn als de werknemers sinds de dag ervoor zijn gestopt.
Nieuwe pogingen, uitstel en idempotente taken
Laravel probeert automatisch taken opnieuw die een uitzondering genereren, afhankelijk van $tries, $backoff of $retryUntil. Dit is handig voor een API van derden die tijdelijk niet beschikbaar is. Dit is gevaarlijk voor een baan waarbij geld wordt verzonden, een factuur wordt aangemaakt of een niet-idempotente webhook wordt aangeroepen.
Pragmatische regels:
- Exponentieel uitstel in plaats van tien pogingen in tien seconden voor dezelfde structurele fout.
$maxExceptionsom een foutieve taak te stoppen voordat de wachtrij leeg is.- Idempotence: een tweede pas mag het effect niet verdubbelen (unieke sleutel in basis, Redis-slot, status “reeds verwerkt”).
'ShouldBeUnique'-taken en snelheidsbeperkende middleware voorkomen ook stormen wanneer honderdduizend commando's dezelfde verwerking activeren.
Mislukte taken, Horizon en waarschuwingen die er toe doen
De tabel failed_jobs (of het Horizon-scherm) is uw fail-wachtrij. Veel teams activeren het tijdens de migratie en raadplegen het vervolgens nooit.
Opstellen:
- Waarschuwing als
failed_jobs> 0 op kritieke wachtrijen (betalingen,meldingen). - Dashboard Horizon of Prometheus-statistiek op
queue_size,jobs_processed,failed_jobs_total. - Procedure: die opnieuw start (
queue:retry all), die na correctie wordt verwijderd en die het incident traceert.
Horizon centraliseert Redis-monitoring: wachttijd, doorvoer, actieve werknemers. Zonder Horizon detecteert een cron-script dat de leeftijd van de oudste taak in Redis controleert (LLEN, LRANGE) al een dode werknemer.
Implementatie, supervisor en de val van zombiewerkers
Een implementatie die de code vervangt zonder de werkrollen opnieuw op te starten, voert soms urenlang de oude versie van taken uit. Laravel documenteert queue:restart om een sierlijke herlaadbeurt aan te geven.
Controlelijst voor implementatie:
php artisan wachtrij: herstartna het updaten van de code.- Supervisor (of systemd) met
autorestart=true. - Scheid zware wachtrijen (
--queue=default,emails) om urgente taken niet te blokkeren.
Op Docker Compose of Kubernetes is een worker niet “zomaar een container”: hij moet dezelfde imageversie hebben als de app, dezelfde omgevingsvariabelen en een statuscheck die verifieert dat hij op de juiste manier verbruikt – en niet alleen dat hij draait.
De top: de wachtrij verbergt een bedrijfsfaillissement
Dit is wat de tutorials "Laravel in de wachtrij in 5 minuten" weglaten.
De staart is een uitgestelde belofte. Zonder zichtbaarheid en zonder een cultuur van 'failed_jobs' besteedt u het probleem uit aan de klantenondersteuning of aan een partner die nooit wordt teruggebeld.
Beslis en ga vooruit zonder blinde vlek
Breng uw banen in kaart: die van cruciaal belang zijn, die vertraging tolereren, die idempotent moeten zijn. Kies een driver aangepast aan uw hosting (Redis op VPS, SQS in de cloud). Configureer nieuwe pogingen met uitstel, foutwaarschuwingen en queue:restart in uw implementatiepijplijn.
Om aanbiedingen te vergelijken met beheerde Redis, inclusief toegewijde werknemers of monitoring, bladert u door onze overzicht en de vergelijker. De gidsen en artikelen door gebruik helpen bij het op maat maken van de infrastructuur rond uw PHP-stack.
Concrete test: dood een arbeider in enscenering, verzend tien taken, controleer de waarschuwing en inhoud van failed_jobs. Als er binnen een kwartier niemand wordt gewaarschuwd, is de wachtrij nog niet operationeel.
Veelgestelde vragen
Welke staartdriver moet je kiezen met Laravel?
Redis of SQS voor productie met meerdere medewerkers; database is geschikt voor kleine volumes. Het sync-stuurprogramma mag nooit in productie blijven: het verbergt gelijktijdigheid en time-outs.
Wat te doen met taken die na alle nieuwe pogingen mislukken?
Ze komen terecht in 'failed_jobs'. Waarschuw, analyseer, repareer en probeer het vervolgens opnieuw met queue:retry of verwijder na tracering - zorg ervoor dat ze zich niet opstapelen.
Moet Horizon op een kleine VPS staan?
Zodra er meerdere werknemers of cruciale taken in het spel zijn, vereenvoudigt Horizon de monitoring. Bij een enkel proces kunnen in eerste instantie een health cron en waarschuwingen over failed_jobs voldoende zijn.
Hoe bepaal je het aantal werknemers?
Scheid wachtrijen op basis van het laadtype en meet de langzaamste taak. Het vermenigvuldigen van werknemers in een wachtrij die wordt geblokkeerd door externe oproepen zorgt alleen maar voor meer parallelle verbindingen, en niet voor meer bruikbare doorvoer.
De volgende keer dat een implementatie ‘succesvol’ is, controleer dan één ding: is een medewerker nog steeds bezig met het verwerken van de wachtrij – en verschijnen de fouten ergens?