Een Symfony e-commerce verstuurt de PDF-factuur via Messenger zodra een bestelling betaald is. Het AMQP-transport is geconfigureerd, de werkrollen zijn actief, behalve dat de PDF-generatieservice twintig minuten lang een 503-fout retourneert. Bij automatische nieuwe pogingen wordt hetzelfde bericht veertig keer herhaald. Resultaat: veertig e-mails naar de klant en een verzadigde wachtrij die de echte incidenten verbergt.
Messenger is niet zomaar een “magische bus”. Het is een contract tussen het moment dat u een bericht verzendt en het moment dat een afhandelaar het uitvoert – met transportkeuzes, beleid voor opnieuw proberen, middleware en transportfouten. Elke optie verandert de veerkracht en het risico op duplicatie.
Transporten: synchronisatie, Doctrine, Redis, AMQP
Symfony routeert berichten via transporten die zijn geconfigureerd in messenger.yaml. De routing (App\Message\* -> async) bepaalt waar elke klasse naartoe gaat.
| Vervoer | Gebruiksscenario's | Punt van waakzaamheid |
|---|---|---|
| synchroniseren | Ontwikkeling ultrasnelle handlers | Latentie en time-outs in productie maskeren |
| doctrine://default | Klein volume, geen Redis | messenger_messages tabel, basissloten |
| redis:// | Lichtlijnen, lage exploitatie | Redis-persistentie, bericht TTL |
| amqp:// (RabbitMQ) | Productie door meerdere werknemers, DLX | Topologie-uitwisselingen en te documenteren bestanden |
Op één VPS kan Doctrine genoeg zijn voor honderden berichten per uur. Zodra de handlers externe API's aanroepen of langer dan een paar seconden duren, vermijdt een toegewijde makelaar het blokkeren van webverzoeken en vereenvoudigt hij de horizontale schaling van 'messenger:consume'-werknemers.
Kiezen voor transport betekent kiezen wie de leveringsgarantie draagt – en niet alleen waar de JSON moet worden opgeslagen.
Nieuwe pogingen, vertragingen en tijdelijke versus permanente fouten
De component RetryStrategy (max_retries, delay, multiplier) probeert mislukte berichten opnieuw. Als u geen onderscheid maakt tussen 'API niet beschikbaar' en 'ongeldige payload', versterkt u een codefout.
Pas enkele nieuwe pogingen toe (drie tot vijf) met exponentieel uitstel van netwerkfouten. Gooi 'UnrecoverableMessageHandlingException' voor definitieve zakelijke fouten. Stel een handlertime-out in: een handler die voor onbepaalde tijd wacht op een derde partij blokkeert een hele werknemer.
Test in fasering: sluit opzettelijk de doelservice af en observeer het gedrag van de wachtrij - niet alleen het handlerlogboek.
Mislukkingstransport en gecontroleerde herhaling
Nadat alle nieuwe pogingen zijn uitgevoerd, kan Messenger doorsturen naar een failure transport (failed://, speciale wachtrij of Doctrine-tabel). Dit is uw quarantainezone.
Alert wanneer het faaltransport niet leeg is. Gebruik messenger:failed:show en messenger:failed:retry voor opnieuw afspelen na reparatie. Definieer een bewaarbeleid: bewaar geen zes maanden aan dode berichten zonder analyse.
Zonder storingstransport kunnen berichten, afhankelijk van de configuratie, worden verwijderd of een medewerker in een lus worden geblokkeerd – twee verschillende manieren om de zichtbaarheid te ‘verliezen’.
Werknemers, toezicht en consistentie van de inzet
messenger:consume async -vv --time-limit=3600 --memory-limit=128M werknemers moeten onder toezicht staan, net als productiediensten. Na de implementatie start u de werkers opnieuw op (signaal of --stop-when-empty en vervolgens opnieuw opstarten). Zorg voor dezelfde codeversie en omgevingsvariabelen als PHP-FPM. Stel geheugenlimieten en tijdslimieten in om langzame lekken te voorkomen.
Op Kubernetes voorkomt een afzonderlijke implementatie voor consumenten het schalen van webpods wanneer alleen de wachtrij groeit. Automatisch schalen op bestandslengte (KEDA, Prometheus) schaalt de juiste component – niet het HTTP-front.
Middleware, routing en vergeten synchrone handlers
Controleer of elk kritisch bedrijfsbericht ‘async’ verloopt. Een zware handler die gesynchroniseerd blijft, zorgt voor nginx-time-outs en periodieke 502-fouten die moeilijk te reproduceren zijn.
De middleware 'DoctrinePingConnectionMiddleware' en 'DoctrineCloseConnectionMiddleware' vermijden verouderde MySQL-verbindingen op langlopende werkers - een klassieker op gedeelde hosting of een beheerde database met agressieve time-out.
De top: transport garandeert geen zakelijke semantiek
De vraag is dus niet “Redis of RabbitMQ?” " Eerst. Het is: wat gebeurt er als deze handler twee keer wordt uitgevoerd? Zolang het antwoord vaag is, is transport slechts een infrastructuurdetail.
Beslis en ga vooruit zonder blinde vlek
Maak een lijst van uw berichten met een aanvaardbare latentie, kriticiteit en idempotence. Kies daarom voor transport en faaltransport. Configureer nieuwe pogingen met uitstel, bewaak werknemers en test het falen van de downstream-service tijdens de fasering vóór productie.
Om Redis, RabbitMQ of werknemers op Europese VPS en cloud te rangschikken, raadpleegt u de overzicht en de vergelijker. De gidsen completeren het PHP-infrastructuurframework. Nuttige oefening: simuleer een permanente uitzondering: het bericht moet in het fouttransport terechtkomen zonder de hele wachtrij te blokkeren.
Veelgestelde vragen
Wat is het verschil tussen synchronisatie en async in Messenger?
Het synchronisatietransport voert de handler onmiddellijk uit in het HTTP-verzoek - handig tijdens de ontwikkeling, gevaarlijk tijdens de productie voor langzame taken. Async verzendt het bericht naar een wachtrij die door afzonderlijke werknemers wordt gebruikt.
Transportdoctrine of Redis/AMQP?
Doctrine is geschikt voor kleine projecten zonder een toegewijde makelaar, maar de berichtentabel wordt een knelpunt. Redis of AMQP schalen beter naarmate het volume, de latentie of het parallellisme toenemen.
Waar wordt faaltransport voor gebruikt?
Het isoleert mislukte berichten na uitputting van nieuwe pogingen, voor inspectie en handmatig afspelen. Als er geen fouttransport is geconfigureerd, kunnen berichten verdwijnen of het verbruik blokkeren.
Hoe vermijd ik duplicaten bij nieuwe pogingen?
Maak handlers idempotent (vergrendelen, basisstatus) en beperk nieuwe pogingen bij niet-tijdelijke fouten. Gebruik unieke bedrijfssleutels. Vertrouw niet standaard op exact één keer leveren.
Voordat u de makelaar optimaliseert, moet u een eenvoudige vraag stellen: als dit bericht twee keer wordt verwerkt, overleeft uw bedrijf dan?