- Laravel redovi čekanja oslanjaju se na dobro definirane veze, drajvere i radnike, koji moraju biti zajedno podešeni kako bi sigurno pregledali i obradili poslove.
- Napredne funkcije poslova kao što su atributi, middleware, jedinstvenost, grupiranje i ulančavanje pružaju preciznu kontrolu nad tim kada i kako se izvršavaju poslovi u redu čekanja.
- Laravel Horizon i alati za neuspješne zadatke olakšavaju praćenje stanja reda čekanja, analizu uskih grla u performansama i sigurno ponovno pokušavanje ili odbacivanje problematičnih zadataka.
- Robusni alati za testiranje i lažiranje osiguravaju da ponašanje vašeg reda čekanja ostane uočljivo i pouzdano prije nego što problemi ikada dođu do produkcije.
Inspekcija poslova u redu čekanja u Laravelu je mnogo više od provjere da li je zadatak na čekanju ili je završen; To uključuje razumijevanje kako funkcioniraju veze i redovi čekanja, kako se radnici ponašaju u produkciji, kako ograničiti, zakazati i pratiti poslove te kako reagirati kada nešto ne uspije. Moderni Laravel dodaje moćne alate poput atributa, middlewarea i Horizona pored klasičnog sistema redova čekanja tako da možete vidjeti, kontrolirati i debugirati ono što se zaista događa u pozadini vaše aplikacije.
Ako se redovno bavite dugotrajnim zadacima kao što su slanje e-pošte, obrada CSV datoteka, manipulisanje slikama ili pristup udaljenim API-jima, Mogućnost istraživanja, prioritizacije, regulisanja i ponovnog pokušaja zadataka na siguran način je ključna. U ovom vodiču ćemo proći kroz cijelu sliku: od osnovne konfiguracije reda čekanja i klasa zadataka do jedinstvenih i šifriranih zadataka, middlewarea, odgođenog izvršavanja s atributima kao što su #, lanci i serije poslova, praćenje Laravel Horizona, rukovanje neuspjelim poslovima, podešavanje radnika, pa čak i kako testirati i lažirati svoje redove čekanja.
Razumijevanje Laravel redova čekanja, konekcija i drajvera
Laravel nudi objedinjeni API za redove čekanja na više backendova kao što su baza podataka, Redis, Amazon SQS i Beanstalkd, plus sinhroni i nulti drajver za lokalni razvoj ili odbacivanje poslova. Sve počinje u config/queue.php, gdje definirate svoj red čekanja Veze i njihove zadane redove čekanja, ponašanje ponovnog pokušaja i vremenska ograničenja.
Ključni koncept za ispravnu inspekciju poslova je razlika između veze i reda čekanja: a veza predstavlja pozadinsku uslugu (na primjer, redis, sqs, database), dok svaka veza može imati više imenovanih pismo kao default, emails, high or lowKada pošaljete posao bez specificiranja reda čekanja, Laravel ga smješta u red čekanja definiran u konekciji. queue opcija.
Ovo odvajanje vam omogućava da klasifikujete i odredite prioritete radnih opterećenja jednostavnim prebacivanjem u različite redove čekanja na istoj vezi, a kasnije pokrenuti radnike koji slušaju samo određene redove ili im daju prioritet u određenom redoslijedu; na primjer, radnik se može pokrenuti sa php artisan queue:work --queue=high,low tako da sve high poslovi se obrađuju prije bilo čega u low.
Svaki vozač ima nekoliko posebnih zahtjeva koje morate ispuniti prije nego što možete sigurno pregledati i obraditi poslove, kao što su tabele baze podataka za database drajver, ispravna Redis konfiguracija za redis drajver i AWS akreditacije za SQS. Bez ove osnove, alati za pregled redova čekanja neće imati ništa konzistentno za praćenje.
Drajveri baze podataka i Redisa, detalji blokiranja i konfiguracije
Kada se koristi drajver reda čekanja u bazi podataka, poslovi su jednostavno redovi u tabeli baze podataka, što čini direktnu inspekciju trivijalnom sa SQL-om. U modernom Laravelu ova tabela se obično kreira zadanom migracijom create_jobs_table, ali ako je vaš projekat stariji ili prilagođen, možete ga generirati pomoću php artisan make:queue-table (ili queue:table u ranijim verzijama) i zatim pokrenite php artisan migrate.
Redis drajver zahtijeva Redis konekciju definiranu u config/database.php, i pohranjuje poslove u Redis liste i povezane ključeve. Prilikom korištenja Redis klastera, nazivi redova čekanja moraju sadržavati hashtag kao što je {default} tako da svi povezani ključevi završe u istom hash slotu; u suprotnom možete naići na suptilne greške gdje je jedan logički red raspoređen na više slotova.
Inspekcija i performanse su u velikoj mjeri pod utjecajem block_for opcija povezivanja s redom čekanja Redis, što govori drajveru koliko dugo treba da se blokira dok čeka novi zadatak prije nego što se ponovo pokrene u petlji. Vrijednost poput 5 sekundi obično smanjuje nepotrebno ispitivanje i korištenje CPU-a u poređenju sa kontinuiranim korištenjem Redisa u uskoj petlji.
I veze s bazom podataka i Redis veze otkrivaju retry_after opcija u config/queue.php koji kontroliše istek posla, što znači koliko dugo se posao može smatrati "u toku" prije nego što sistem pretpostavi da je radnik umro i vrati posao u red čekanja. Za tačnu inspekciju morate postaviti retry_after biti nešto duži od maksimalnog vremena koje je razumno potrebno za posao.
Drugi drajveri poput Amazon SQS i Beanstalkd dolaze sa svojim vlastitim preduvjetima, uključujući Composer pakete kao što su aws/aws-sdk-php za SQS ili pda/pheanstalk za Beanstalkd i vremenska ograničenja vidljivosti specifična za SQS konfigurirana na strani AWS-a umjesto retry_after vrijednosti u queue.php.
Kreiranje, strukturiranje i inspekcija poslova
Po konvenciji, Laravel drži poslove koji se mogu čekati u redu čekanja u app/Jobs imenik, i možete ih generirati pomoću php artisan make:job SomeJobName, nakon dobrog programska logikaImplementacija generiranih poslova Illuminate\Contracts\Queue\ShouldQueue, što signalizira okviru da ih gurne u red umjesto da ih pokreće inline.
Tipična klasa poslova sadrži konstruktor za prikupljanje podataka i handle metoda gdje se posao zapravo odvija, na primjer obrada otpremljenog podcasta, promjena veličine slika ili slanje e-pošte dobrodošlice. Zahvaljujući osobinama kao što su Queueable, Dispatchable, InteractsWithQueue i SerializesModels, većina standardnih postavki za otpremu i serijalizaciju se rješava umjesto vas.
Jedna moćna funkcija prilagođena inspekciji je transparentna serijalizacija Eloquent modela, gdje se samo identifikator modela pohranjuje u korisnom teretu, a cijeli model (sa svojim odnosima) se lijeno ponovo učitava kada se posao pokrene. Ovo održava korisne terete malim i predvidljivim, a istovremeno vam omogućava da pregledate poslove i dalje vidite na kojim ID-ovima modela rade.
Kada poslovi uključuju teške ili složene odnose, možda ih uopće ne želite serijalizirati, u tom slučaju možete ukloniti odnose putem $model->withoutRelations(), ukloniti pojedinačne odnose ili u modernom Laravelu označiti specifična svojstva koja promoviraju konstruktori ili čak cijele klase poslova sa WithoutRelations atribut tako da korisni tereti ostaju kompaktni i fokusirani.
Binarni podaci poput sirovih slika ili sadržaja datoteka nikada se ne smiju direktno unositi kao stringovi u svojstva zadatka, jer će ih JSON serijalizacija vjerovatno oštetiti; umjesto toga, kodirajte taj sadržaj u base64 ili ga negdje pohranite (disk, S3, baza podataka) i pustite da ga zadatak ponovo dohvati po referenci kada se izvrši.
Otpremanje, odgađanje i uvjetno izvršavanje poslova
Slanje posla je obično jednostavno kao pozivanje njegovog statičkog dispatch metoda, na primjer ProcessPodcast::dispatch($podcast) iz kontrolera. U nastavku se kreira instanca i šalje se na konfiguriranu vezu i u red čekanja, spremna za preuzimanje od strane radnika.
Ako trebate odmah pokrenuti zadatak u trenutnom procesu umjesto da ga stavite u red čekanja, možeš koristiti dispatchSync (ili stariji dispatchNow), što je korisno za testove ili operacije koje se moraju završiti prije vraćanja odgovora. Laravel također pruža odgođeno sinhrono slanje putem deferred i background veze, što vam omogućava da obrađujete poslove nakon što je HTTP odgovor poslan bez potrebe za zasebnim radnim procesom na nivou sistema.
Uslovno slanje je jednostavno uz pomoćne funkcije kao što su dispatchIf i dispatchUnless, koji izvršavaju posao samo kada je dati uslov tačan ili netačan. Ovaj obrazac održava vaše klase poslova fokusiranim, a logiku otpreme čini čitljivom i samodokumentovanom.
Prilikom rada unutar transakcija baze podataka, uobičajeno je stavljati u red poslove koji zavise od zapisa koji su upravo kreirani ili ažurirani, ali radnici mogu pokrenuti te poslove prije nego što se transakcija potvrdi, što uzrokuje nedostajuće podatke ili zastarjela stanja. Da biste to riješili, možete uključiti after_commit opcija za vezu reda čekanja ili eksplicitno lančanje ->afterCommit() na određenim otpremama tako da se poslovi otpuštaju tek nakon što se potvrde sve otvorene transakcije.
Suprotno tome, ako je veza konfigurirana za slanje nakon commita po defaultu i potrebno vam je da se posao odmah pokrene, možeš nazvati ->beforeCommit() (ili odgovarajuću metodu za vašu Laravel verziju) da biste se isključili i omogućili trenutno stavljanje u red, što može biti korisno kada sam posao obavlja kompenzacijski rad u slučaju da kasniji korak ne uspije.
Zakazivanje izvršavanja reda čekanja s atributom #
Laravel je historijski koristio delay() metoda na kreatoru otpreme za odgađanje izvršenja posla, kao Job::dispatch()->delay(now()->addMinutes(10)), ali moderni Laravel (13.5 i noviji) uvodi čistiji i deklarativniji pristup koristeći izvorni PHP atribut #.
sa # vrijeme čekanja definirate direktno na klasi posla, na primjer #, držeći pravila vremenskog rasporeda tamo gdje im je mjesto umjesto da se rasprše po kontrolerima i servisima. Ovo znatno olakšava inspekciju poslova jer su i ponašanje i raspoređivanje vidljivi unutar definicije posla.
Atribut podržava više jedinica kao što su sekunde, minute, sati i dani, tako da možete pisati zadatke poput brzog zadatka od 30 sekundi, generiranja izvještaja od 2 sata ili podsjetnika za napuštenu korpu za 1 dan s ekspresivnim atributima umjesto ad-hoc izračuna datuma u vrijeme otpreme.
Praktični slučajevi upotrebe uključuju slanje e-maila dobrodošlice sat vremena nakon registracije, podsjećanje korisnika na napuštene korpe nakon 24 sata, odgađanje generiranja mjesečnih izvještaja za nekoliko sati zbog perioda van vršnih opterećenja ili čišćenje privremenih datoteka 12 sati nakon što su kreirane. U svakom slučaju, pravilo vremena se nalazi u klasi posla, što pojednostavljuje i pregled koda i operativnu inspekciju.
Možete bezbedno kombinovati # sa drugim atributima kao što su # ili svojstva povezana s ponovnim pokušajem, izgradnja poslova koji ne samo da počinju kasnije, već i izbjegavaju istovremenu modifikaciju istog resursa i primjenjuju pravila odgode ili ponovnog pokušaja. Ono što biste trebali izbjegavati je miješanje # i ->delay() na istoj otpremi posla, jer postaje nejasno koje pravilo treba da pobijedi i komplikuje otklanjanje grešaka.
Middleware za poslove, ograničavanje brzine i sprječavanje preklapanja
Middleware za poslove vam omogućava da obuhvatite međusektorsku logiku oko izvršenja posla, slično kao što HTTP middleware obavija zahtjeve. Umjesto da zatrpava handle metodu sa zaključavanjem, ograničavanjem ili sigurnosnim provjerama, te probleme možete sažeti u namjenske klase middlewarea.
Klasičan primjer je ograničavanje brzine izvršavanja zasnovano na Redisu, gdje želite da se samo jedna instanca zadatka izvršava svakih nekoliko sekundi, kao što je slanje obavještenja vanjskom API-ju sa strogim ograničenjima brzine. Iako možete pozvati Redis::throttle() direktno u handleStavljanje te logike u middleware održava sam posao čistim i omogućava vam ponovnu upotrebu istog limitera u više poslova.
Laravel dolazi s praktičnim middlewareom kao što je RateLimited i RateLimitedWithRedis, koji se vežu za RateLimiter definicije fasada koje konfigurirate u AppServiceProvider::boot()Ovi middleware-i mogu automatski vraćati poslove u red čekanja kada se prekorače ograničenja, povećavajući pokušaje i primjenjujući odgodu u skladu s vašim atributima ili retryUntil metoda.
Da biste spriječili da dva posla istovremeno dodiruju isti resurs, možete vratiti WithoutOverlapping middleware iz posla middleware() metoda s ključem zasnovanim na nečemu poput korisničkog ID-a ili ID-a narudžbe. Preklapajući poslovi će biti odgođeni ili izbrisani ovisno o vašoj konfiguraciji, a također možete postaviti eksplicitni istek zaključavanja s expireAfter kako bi se izbjeglo trajno zadržavanje brava u slučaju pada sistema.
Rukovanje nestabilnim uslugama trećih strana je mnogo lakše uz ThrottlesExceptions posrednički softver, ...koji broji izuzetke i počinje odlagati daljnje pokušaje nakon što se prekorači određeni prag. Možete konfigurirati koliko je izuzetaka dozvoljeno, koliko dugo čekati nakon toga, pa čak i koji izuzeci trebaju pokrenuti ograničavanje, a sve to uz razlikovanje privremenih kvarova od trajnih, poput opoziva dozvola.
Jedinstveni, debounced i šifrirani poslovi
Ponekad će vaša inspekcija pokazati mnogo identičnih poslova u redu čekanja koji su trebali biti sažeti u jedan, na primjer prilikom ažuriranja indeksa pretrage ili sinhronizacije proizvoda s vanjskom uslugom. Da bi se ovo riješilo, Laravel nudi ShouldBeUnique i ShouldBeUniqueUntilProcessing ugovori koji osiguravaju da se u redu čekanja u datom trenutku nalazi samo jedan posao s datim jedinstvenim ključem.
Ključ jedinstvenosti možete definirati putem uniqueId metoda ili atribut kao što je UniqueFor, često ga povezujući s ID-om proizvoda, ID-om korisnika ili sličnim identifikatorom. Laravel koristi sistem keša za dobijanje brave prilikom slanja i otpušta je kada se posao završi ili iscrpi sve ponovne pokušaje, a možete odabrati koju pohranu keša ćete koristiti putem uniqueVia metoda.
Drugi obrazac su debounced poslovi, gdje česta slanja u kratkom prozoru trebaju biti prekinuta tako da se izvršava samo posljednja, kao što je spremanje često uređivanih postavki ili strimovanje promjena u indeks pretrage. Sa DebounceFor atributom možete reći Laravelu da odgodi izvršenje za definirani interval i odbaci starije zadatke na čekanju za isti ključ, čak i prilikom pokretanja JobDebounced događaj kada se to desi.
Ako vam je važna povjerljivost sadržaja posla, možete implementirati ShouldBeEncrypted interfejs na radnom mjestu, Dakle, Laravel automatski šifrira serijalizirani posao prije nego što ga pošalje u backend. Ovo je korisno kada trebate pregledati metapodatke posla na visokom nivou, ali ne možete otkriti sirove adrese e-pošte, tokene ili lične podatke u tranzitu ili u stanju mirovanja u backendu za red čekanja.
Zajedno, jedinstvenost, debouncing i enkripcija čine redove čekanja sigurnijim i predvidljivijim, osiguravajući da slučajno ne preopterećujete eksterne servise, ne curite osjetljive podatke ili ne rasipate resurse na obradu duplih radnih opterećenja, što zauzvrat pojednostavljuje operativne kontrolne ploče i ručne inspekcije.
Lančano povezivanje poslova, serije i napredna orkestracija
Za tokove rada gdje se više koraka mora izvršavati u nizu, ulančavanje poslova vam omogućava da stavite u red primarni zadatak nakon čega slijedi lista zavisnih poslova, koji se svi izvršavaju samo ako prethodni uspije. Možete ulančati putem Bus::chain() ili pomagače poput ProcessPodcast::withChain(), a možete i lančano povezivati zatvaranja, ne samo klase.
Lančani poslovi mogu dijeliti istu vezu i red čekanja korištenjem onConnection i onQueue, i možete registrovati catch zatvaranje za obradu bilo kakvog kvara u lancu, primajući tačan izuzetak koji ga je uzrokovao. Ovo olakšava pregled zašto je sekvenca zaustavljena i reagovanje u skladu s tim, kao što je slanje upozorenja ili vraćanje djelomičnog rada.
Kada želite da izvršavate više poslova paralelno, a zatim reagujete tek kada se svi završe, U obzir dolaze serije poslova izgrađene na Laravelovom komandnom magistrali. Seriju definirate putem Bus::batch(), priložite then, catch i finally povratne funkcije, opcionalno mu dajte prijateljsko ime i otpremite ga. Serije se prate u namjenskom skladištu (baza podataka ili DynamoDB) tako da možete upitati status, napredak i neuspjehe.
Serije mogu sadržavati jednostavne poslove, ugniježđene lance, pa čak i hijerarhije gdje jedan posao hidratizira seriju dodatnim radom, što je posebno korisno za velike uvoze gdje prvo podijelite datoteku, a zatim otpremite zadatke obrade za svaki dio. Možete čak i dodati zadatke u pokrenutu seriju iz samog zadatka koristeći batch() pomagač i add() metoda.
Za dugotrajne sisteme, trebat ćete ukloniti stare batch metapodatke kako biste izbjegli neograničen rast tabela ili DynamoDB particija. što se obično radi pomoću queue:prune-batches Artisan komanda po rasporedu, s opcijama za uklanjanje samo starih, nedovršenih ili otkazanih serija i, u slučaju DynamoDB-a, konfiguriranjem TTL atributa tako da AWS automatski briše istekle zapise.
Pokretanje, podešavanje i inspekcija radnika u redu čekanja
Glavni mehanizam koji troši vaše poslove u redu čekanja je queue:work Zanatska komanda, što pokreće dugotrajni radni proces koji nastavlja dohvaćati i izvršavati zadatke dok se ne zaustave. Za otklanjanje grešaka možete koristiti --once or --max-jobs opcije za obradu ograničenog broja poslova, ili --max-time za izlazak nakon određenog broja sekundi.
Radnici mogu slušati određenu vezu i listu reda čekanja, na primjer php artisan queue:work redis --queue=emails or --queue=high,low, tako da tokom inspekcije tačno znate koji je radnik odgovoran za koje radno opterećenje. Ako trebate obrisati sve neriješene poslove u redu čekanja, queue:clear dostupan je s parametrima veze i reda čekanja.
Dvije kritične postavke za vrijeme izvođenja su radnik --timeout i veze retry_after, koji moraju biti usklađeni zajedno: vrijeme čekanja mora uvijek biti nekoliko sekundi kraće od retry_after Dakle, zaglavljeni radnik se uništava prije nego što se posao ponovo pusti za još jedan pokušaj. Ako ih postavite pogrešnim redoslijedom, poslovi se mogu obraditi dva puta ili neispravno označiti kao neuspješni.
Radnici su također pogođeni --sleep, koji kontroliše koliko dugo pauziraju kada nema dostupnih poslova, i prema načinu održavanja: radnici po zadanim postavkama zaustavljaju obradu tokom održavanja, ali ovo možete poništiti pomoću --force zastavica. Laravel također podržava pauziranje radnika na nivou reda čekanja sa queue:pause a kasnije ih nastavljajući sa queue:continue.
Budući da su radnici u redovima dugovječni demoni, potreban vam je upravitelj procesa kao što je Supervisor (na Linuxu) ili systemd servisi kako biste osigurali da ostanu aktivni. ponovno pokretanje u slučaju kvara i skaliranje pokretanjem više radnih procesa. Konfiguracije nadzornika obično deklariraju numprocs, Artisanova naredba za pokretanje, zapisivanje putanja, ponovno pokretanje politika i stopwaitsecs koji mora biti duži od vašeg najdužeg trajanja zaposlenja.
Praćenje i inspekcija redova čekanja pomoću Laravel Horizon-a
Za redove čekanja podržane Redisom, Laravel Horizon dodaje prekrasnu kontrolnu ploču u stvarnom vremenu, nudeći dubok uvid u zadatke na čekanju, pokrenute, završene i neuspješne zadatke, kao i propusnost, vrijeme izvršavanja i statistiku radnika. Umjesto ručnog pregledavanja Redisa ili čitanja logova, možete se prijaviti u Horizon UI i odmah vidjeti kako se vaši redovi čekanja ponašaju pod opterećenjem.
Instalacija je jednostavna putem Composera i php artisan horizon:install, koji objavljuje config/horizon.php datoteka u kojoj konfigurirate nadzornike, veze s redovima čekanja, strategije balansiranja i ograničenja poput broja procesa koje treba pokrenuti ili koje redove čekanja pratiti. Pokretanje Horizona je jednostavno kao i pokretanje... php artisan horizon, ali u produkciji biste ga ponovo trebali pokretati pod Supervisorom ili systemd-om da biste ga održali aktivnim.
Horizon kontrolna tabla je podijeljena na odjeljke za trenutna opterećenja, neuspješne zadatke, metrike i nedavne aktivnosti, i omogućava vam da pregledate pojedinačne zadatke, ponovo pokušate ili izbrišete neuspjehe i vidite koliko obično traje izvršavanje određenih tipova poslova. Ova vidljivost je neprocjenjiva kada trebate razumjeti skokove, usporavanja ili ponovljene kvarove bez korištenja više alata.
Pored inspekcije sirovih podataka, Horizon podržava upozorenja i obavještenja za ključne događaje, Na primjer, kada dužina reda čekanja pređe određeni prag, kada ima previše neuspjelih poslova ili kada određene oznake ukazuju na to da je pogođen kritični klijent. Ova upozorenja mogu se slati putem kanala kao što su pošta ili Slack tako da vaš tim može brzo reagovati bez cjelodnevnog gledanja u kontrolnu ploču.
Horizon vam također pomaže da optimizirate performanse reda čekanja tokom vremena, prikazivanjem koji redovi čekanja ili vrste poslova predstavljaju uska grla, sugeriranjem gdje je potrebno više radnika i olakšavanjem podešavanja konfiguracija nadzornika kako bi kritični redovi čekanja dobili resurse i prioritet koji zaslužuju dok se poslovi niskog prioriteta izvršavaju u pozadini.
Rješavanje neuspjelih zadataka, ponovnih pokušaja i strategija odustajanja
U svakoj ozbiljnoj aplikaciji neki poslovi u redu čekanja će na kraju propasti, a Laravel nudi kompletan tok za evidentiranje, inspekciju, ponovni pokušaj i čišćenje. Neuspjeli asinhroni poslovi se pohranjuju u failed_jobs tabelu (ili DynamoDB tabelu) koju možete kreirati pomoću ugrađenih migracija ili putem namjenskih Artisan komandi.
Maksimalan broj pokušaja koje posao može imati kontrolira se kombinacijom opcija radnika i atributa posla, kao što su --tries on queue:work or Tries/MaxExceptions atribute na samom poslu, a možete navesti i retryUntil metoda za vremenska ograničenja umjesto brojanja pokušaja. Kada zadatak premaši dozvoljeni broj pokušaja, smatra se neuspjelim i to se evidentira.
Konfiguracija odgode određuje koliko dugo Laravel treba čekati prije ponovnog stavljanja zadatka u red čekanja nakon izuzetka. i možete ga postaviti globalno pomoću --backoff ili na osnovu pojedinačnog posla sa Backoff atribut ili backoff() metoda koja vraća ili jednu vrijednost ili niz za eksponencijalne obrasce odugovlačenja.
Kada pregledate neuspješne zadatke i želite ih ponovo pokušati, možeš koristiti php artisan queue:failed da ih nabrojim, queue:retry <id|all> da ih ponovo stave u red čekanja, queue:forget <id> da izbrišete jedan, ili queue:flush da ih sve obrišete, opcionalno ograničeno starošću putem --hours zastavica. Za neuspješne poslove koje podržava DynamoDB, postoji i podrška za uklanjanje starih unosa, a istovremeno čuvanje novijih za analizu.
Poslovi mogu implementirati failed(Throwable $exception) metoda za izvođenje čišćenja kada konačno ne uspiju, slanje upozorenja, poništavanje djelomičnih radnji ili evidentiranje dodatnog konteksta. Tip izuzetka vam govori da li je neuspjeh bio uzrokovan maksimalnim brojem pokušaja, vremenskim ograničenjem ili stvarnim izuzetkom. handle, što može voditi vašu logiku sanacije.
Za dodatnu kontrolu možete i ručno pozvati $this->fail() or $this->release() iznutra posla, opcionalno prosljeđivanje kašnjenja za odgađanje sljedećeg pokušaja. Middleware kao što je FailOnException Omogućava vam skraćivanje pokušaja kad god se pojave određene vrste izuzetaka, podržavajući nijansirane strategije gdje se prolazni problemi ponovo pokušavaju riješiti, ali zabranjene greške trajno ne uspijevaju.
Testiranje, lažiranje i programska inspekcija redova čekanja
Efektivna inspekcija se ne zaustavlja u proizvodnji; vaši testovi trebaju potvrditi kako se poslovi raspoređuju i povezuju, i Laravelov Queue::fake() i Bus::fake() To znatno olakšava. Falsificiranjem reda čekanja sprječavate stvarno izvršavanje poslova, a i dalje možete provjeriti da li su poslani s ispravnim tipovima i podacima.
Pomagači poput Queue::assertPushed, assertNotPushed, assertClosurePushed i njihove negacije Omogućavaju vam da izrazite očekivanja u smislu klasa poslova ili čak zatvaranja koja provjeravaju instance poslova za određene atribute. Također možete lažirati samo određene poslove ili lažirati sve osim skupa, što vam omogućava da miješate stvarno i lažno ponašanje u istom testnom paketu.
Za lance, Bus::assertChained i assertDispatchedWithoutChain pomoći u potvrđivanju orkestracije posla, dok su tvrdnje vezane za serije, kao što su assertBatched i assertBatchCount Provjerite jesu li grupe poslova ispravno grupirane u pakete, s očekivanim tipovima poslova prisutnim u definicijama paketa.
Ponekad je potrebno testirati kako posao interaguje sa svojim životnim ciklusom reda čekanja, kao što je vraćanje sebe za kasnije ili brisanje sebe pod određenim uslovima; za taj scenario, Laravel pruža pomoćne funkcije za ubacivanje lažnih interakcija reda čekanja u instancu posla, pokretanje handle a zatim potvrditi metode poput assertReleased or assertDeleted na lažnom sloju.
Konačno, sistem redova čekanja izlaže događaje niskog nivoa i povratne pozive za dodatnu instrumentaciju, uključujući Queue::before, Queue::after, Queue::looping, Queue::failing i QueueBusy događaji koje je pokrenuo queue:monitor, a sve se to može povezati s vašim pružateljima usluga za praćenje metrika, prikazivanje prilagođenih nadzornih ploča ili integraciju s vanjskim platformama za praćenje.
Spajanje svih ovih dijelova – od dobro strukturiranih poslova i atributa poput # do middleware-a, Horizon kontrolnih ploča, robusnog rukovanja greškama i temeljitih testova – Na kraju dobijate Laravel redove čekanja koji su ne samo moćni, već i lako dostupni za inspekciju, tako da kada nešto uspori, zakaže ili se ponaša neočekivano, imate alate i uvid u stanje vašeg pozadinskog rada i omogućavate nesmetan rad vaše aplikacije.
