v13.39.0 en passen we de basisbewerkingen uit Taakplanning toe op packageontwikkeling. Zie De interne structuur van package discovery voor het laden van providers en Packageconfiguratie samenvoegen en cachen voor het publiceren van configuratie.
Registreren nadat Schedule is geresolved
In een gewone Laravel-applicatie registreertFoundationServiceProvider Schedule::class als singleton. Het aanmaken daarvan roept resolveConsoleSchedule() van de Console Kernel aan, die de tijdzone van de applicatie en de cachestore voor de scheduler toepast.
Een package breidt deze gedeelde Schedule uit en maakt niet simpelweg een eigen new Schedule() aan. De volgende provider gaat uit van een opzet waarin Acme\Courier\ via Composer PSR-4 naar src/ verwijst en het package een config/courier.php heeft.
callAfterResolving() wacht op een toekomstige resolutie als de service nog niet geresolved is, en haalt de service op en roept de callback direct aan als die al geresolved is. Zo wordt de registratie ook toegepast als een andere provider Schedule al eerder heeft gebruikt. Zie Hooks na het resolven van packageservices voor details.
runningInConsole() controleert niet op een specifiek Artisan-command. In dit voorbeeld sluiten we het gebruik van Schedule via HTTP uit. Maak bovendien de provider die de hook registreert zelf geen deferred provider. Als boot() niet op tijd draait, wordt ook de hook niet geregistreerd.
Het registreren van een event en het uitvoeren van een taak zijn twee verschillende dingen. Het laden van deze provider voert de heartbeat niet ter plekke uit. Alleen registreren start ook geen cron of
schedule:work.Gebruikers expliciet laten inschakelen
Deconfig/courier.php van het package staat standaard uitgeschakeld.
schedule.enabled op true. In dit voorbeeld worden de waarden bij het registreren gelezen. De tijdzone staat standaard op UTC; kies je een andere tijdzone, houd dan rekening met dubbele of overgeslagen uitvoeringen door de zomertijd.
Omdat configuratie ondiep wordt samengevoegd, geeft ook de registrar voor elke sleutel een standaardwaarde op. Zo kan de taak met de basisinstellingen worden geregistreerd, zelfs als een gedeeltelijke overschrijving de andere sleutels van de schedule-array laat verdwijnen.
Dubbele registratie in dezelfde Schedule voorkomen
De volgendesrc/CourierSchedule.php registreert een minimale heartbeat die één logregel schrijft. Met WeakMap zorgen we ervoor dat deze registrar maar één keer iets toevoegt aan hetzelfde Schedule-object.
Schedule::call(), exec() en job() voegen een event toe aan een array. Het zijn geen API’s die een event met dezelfde naam opzoeken en vervangen of dubbele events verwijderen.
De eventnaam beïnvloedt ook de compatibiliteit van locks
name() is een alias van description(), maar het effect op de locknaam verschilt per type event. Hieronder staan de standaard mutexnamen.
Geef een CallbackEvent een niet-lege naam vóór
withoutOverlapping() of onOneServer(). Is er geen naam ingesteld, dan gooien deze methoden een exception.
job() gebruikt normaal de naam van de jobklasse of iets dergelijks als initiële naam. Registreer je dezelfde job met verschillende argumenten of doelen, geef dan expliciet per doel een naam op. Alleen het wijzigen van de argumenten maakt van de initiële naam niet automatisch een andere naam.
SyncCatalogJob is een voorbeeld van een jobklasse die het package aanbiedt. Zie Queues en jobs voor het implementeren van jobs.
Als je de naam, het command of de cron-expressie wijzigt, verandert afhankelijk van het type ook de identificatie van de lock. Bij een deployment waarin processen van de oude en nieuwe versie naast elkaar draaien, kunnen ze voor dezelfde verwerking verschillende locks verkrijgen. Behandel dit niet als een simpele wijziging van een weergavetekst, maar beheer taaknamen als een stabiele publieke specificatie.
onOneServer en withoutOverlapping los van elkaar bekijken
onOneServer()kiest welke server de uitvoering op dat tijdstip voor zijn rekening neemt. De onderzochteCacheSchedulingMutexvoegt het uur en de minuut toe aan de mutexnaam van het event en houdt die een uur vast. Dit staat los van de lock tegen overlapping, die wordt vrijgegeven wanneer de taak eindigt.withoutOverlapping()voorkomt overlapping zolang de vorige uitvoering nog loopt. De opgegeven vervaltijd is in minuten, standaard 1.440 minuten. Is de vervaltijd te kort, dan verloopt de lock voordat de verwerking klaar is.- Als
job()iets in de queue plaatst, betekent het voltooien van het schedule-event niet dat de job is verwerkt. Ontwerp de controle op dubbele uitvoering in de worker apart, bijvoorbeeld met unieke jobs of deWithoutOverlapping-middleware aan de kant van de job.
onOneServer() inschakelen erop dat een gedeelde cacheconfiguratie met database, memcached, dynamodb of redis, zoals de officiële documentatie voorschrijft, een vereiste is. Locks garanderen geen exactly-once voor de bedrijfslogica; de verwerking moet ook bestand zijn tegen opnieuw uitvoeren.
Zware afhankelijkheden pas bij uitvoering resolven
DeLoggerInterface van de heartbeat hierboven wordt bij het uitvoeren van het event door CallbackEvent geresolved via call() van de container. In deze opzet wordt er bij het registreren van de hook niets gelogd en geen client aangemaakt.
Een ontwerp zonder externe verbindingen of bedrijfslogica in de constructor is ook belangrijk bij Artisan-commands van een package registreren en afhankelijkheden resolven.
Omdat
call() en job() CallbackEvents zijn, kun je runInBackground() niet gebruiken. Delegeer tijdrovende verwerking aan de queue, of kies indien nodig voor uitvoering op de achtergrond met command().
De configuratie van de hele applicatie niet overnemen
Schedule::useCache() wijzigt de store van het mutex-object dat Schedule bevat. Dit is geen instelling die alleen de events van het package raakt; ook events die dezelfde mutex delen worden beïnvloed. Roep het niet onvoorwaardelijk aan in de boot() van het package, maar behandel het als een instelling die de gebruikende applicatie kiest.
Op dezelfde manier mag een package niet op eigen houtje Schedule::alwaysOnOneServer(), het pauzeren van de scheduler of het uitvoeringsbeleid tijdens de onderhoudsmodus wijzigen.
Na een configuratiewijziging een nieuwe Schedule aanmaken
enabled, de cron-expressie en de tijdzone in het voorbeeld zijn instellingen die bij het registreren worden gelezen. Alleen de waarde van config() wijzigen voor een al aangemaakte Schedule voegt geen events toe of verwijdert ze, en leest de configuratie ook niet opnieuw in. De WeakMap-controle is evenmin bedoeld om opnieuw te configureren.
Bouw bij deployments die de configuratiecache gebruiken de cache opnieuw op, en controleer schedule:list in een proces dat de nieuwe configuratie inleest. Controleer ook voor langlopende schedulers en voor schedule:run die taken van minder dan een minuut uitvoert, dat er geen oude code of configuratie achterblijft. Zie Taakplanning voor het onderbreken van sub-minuuttaken tijdens een deployment.
Registratie los van uitvoering testen
Hieronder staat een voorbeeld vantests/CourierScheduleTest.php dat de Composer-autoload van het package en PHPUnit gebruikt. De mutex wordt vervangen door een test double, zodat je het resultaat van de registratie controleert zonder externe cache of echte cron.
Voer niet alle taken van de gebruikende applicatie uit met
schedule:run alleen om de registratietests te laten slagen. Door tests van de taakbody te scheiden van integratietests van de scheduler in een gecontroleerde omgeving, vermijd je bijwerkingen van niet-gerelateerde geplande taken.
Gerelateerde pagina’s
Taakplanning
Bekijk uitvoeringsfrequenties, het instellen van cron, delegeren aan de queue en het beheer tijdens deployments.
Hooks na het resolven van packageservices
Bekijk het toepassen op nog niet en al wel geresolvede services en de aandachtspunten bij herhaalde registratie.
Geraadpleegde primaire bronnen
- Officiële Laravel-documentatie: Taakplanning
- Officiële Laravel-documentatie: Packageontwikkeling
- FoundationServiceProvider: Schedule registreren als singleton
- Console Kernel: Schedule aanmaken en standaardinstellingen
- ServiceProvider: callAfterResolving()
- Schedule: events toevoegen, jobs uitgesteld aanmaken en de mutex delen
- Event: mutexnaam van command-events
- CallbackEvent: verplichte naam en het resolven van afhankelijkheden bij uitvoering
- CacheEventMutex: lock tegen overlapping en omrekening van de vervaltijd
- CacheSchedulingMutex: lock per uitvoeringstijdstip
- Officiële tests: registratie van events en tijdzones
- Officiële tests: uitgesteld aanmaken via de naam van de jobklasse