Paano i-pause at kontrolin ang mga pila sa Laravel nang sunud-sunod

Informatec Digital » Kayamanan » Paano i-pause at kontrolin ang mga pila sa Laravel nang sunud-sunod

Ang paggamit ng mga pila sa Laravel ay halos mandatoryo sa anumang proyektong medyo seryoso: pagpapadala ng mga email, pagproseso ng mga CSV file, pagbuo ng mga PDF, pagbabago ng laki ng mga imahe, pagtawag ng mga external API… Kung ang lahat ng iyon ay ginagawa sa pangunahing HTTP request, ang website ay magiging mabagal, lilitaw ang 500 error, at ang user ay desperadong nakatitig sa isang blangkong screen.

Ang magandang balita ay nag-aalok ang Laravel ng isang makapangyarihan at flexible na imprastraktura ng pagpila na nagbibigay-daan sa iyong magtalaga ng mabibigat na gawain sa mga proseso sa background, pamahalaan ang mga ito ayon sa prayoridad, pangkatin ang mga ito sa mga batch, subaybayan ang mga ito, subukan muli kapag nabigo ang mga ito, at pansamantalang i-pause ang mga manggagawa para sa maintenance. Tingnan natin nang mabuti (at huwag kalimutan) kung paano masulit ito, kabilang ang kung paano i-pause, ipagpatuloy, at kontrolin ang pag-uugali nito sa produksyon.

Pangunahing konsepto: mga koneksyon, pila, at mga driver

Sa Laravel, bago i-pause ang anuman, kailangan mong maunawaan ang pagkakaiba sa pagitan mga koneksyon sa pila at mga pila mismo. Sa config/queue.php mayroon kang isang array connections kung saan mo tinukoy ang bawat backend: database, redis, beanstalkd, sqs, sync, null, failover, rabbitmq (kung idadagdag mo ito), atbp.

Ang bawat koneksyon ay maaaring magkaroon ng ilang lohikal na mga pila (mga pangalan tulad ng default, emails, high, low, importsAng katangian queue Ang bawat koneksyon ay nagpapahiwatig kung alin ang default na pila kung saan pupunta ang mga trabaho kung walang ibang tinukoy. onQueue()Sa ganitong paraan magagawa mo ang mga bagay tulad ng:

• Isang mabilis na pila para sa mga email o maikling transaksyon.
• Isa pang mababang priyoridad para sa mahahabang gawain tulad ng pagproseso ng mga video o malalaking ulat.
• Mga queue na naka-segment ayon sa uri ng gawain: imports, notificaciones, reportes, Atbp

Kapag inilunsad mo ang manggagawa na may php artisan queue:workBilang default, nakikinig ito sa pila na tinukoy bilang default sa napiling koneksyon. Kung gusto mong bigyang-priyoridad, maaari kang magpasa ng maraming comma-separated queue:

php artisan queue:work redis --queue=high,default,low

Sa ganitong paraan, pinoproseso muna ng worker ang high , pagkatapos ay ang default , at pagkatapos lamang ang low , na mahalaga kapag naka-load ang system at hindi mo gugustuhing harangan ng 30 minutong ulat ang mga email na may mataas na priyoridad.

Mga driver ng pila at mga kinakailangan

Nag-aalok ang Laravel ng pinag-isang API para sa ilang queue driver , ngunit ang bawat isa ay may kanya-kanyang partikular na mga tampok at dependency. Mahalaga ang pagpili ng tamang driver bago pag-usapan ang mga pausing worker.

Database ng driver

Ang driver database Iniimbak nito ang mga trabaho sa isang talahanayan ng SQL (karaniwang jobsMadali itong i-set up at perpekto para sa maliliit na proyekto o mga development environment kung saan hindi mo gustong magulo sa Redis o SQS.

Mga pangunahing hakbang:

• Bumuo ng paglipat: php artisan queue:table (o sa mga mas bagong bersyon, ito ay dumating bilang create_jobs_table default).
• Magpatakbo ng mga paglilipat: php artisan migrate.
• I-configure QUEUE_CONNECTION=database sa .env at kumpirmahin sa config/queue.php ito 'default' => env('QUEUE_CONNECTION','database').

Ito ay maginhawa at sapat na matatag, ngunit sa maraming pila at maraming trapiko maaari itong maging isang bottleneck , dahil ang lahat ay dumadaan sa parehong relational database.

Driver Redis

Ang Redis driver ang karaniwang workhorse sa produksyon. Mabilis ito, sumusuporta sa mga advanced na feature (locking, rate limiting, atomic locks, Horizon, atbp.), at mahusay sa pag-scale.

Mga mahahalagang puntos:

• Kailangan mong i-configure ang Redis na koneksyon sa config/database.php.
• Ang mga pagpipilian serializer y compression mula sa Redis Hindi sila magkatugma kasama ang driver ng pila.
• Kung gumagamit ka Redis ClusterAng mga pangalan ng mga pila ay dapat may hash tag, halimbawa {default}upang ang lahat ng mga susi sa pila na iyon ay mahulog sa parehong puwang.
• Ang pagpipilian block_for Pinapayagan nito ang manggagawa na humarang habang naghihintay ng mga trabaho sa loob ng ilang segundo, sa halip na patuloy na pagboto: nakakatipid ng CPU at binabawasan ang mga query sa Redis server.

Por ejemplo:

'redis' => ,

Kung ilalagay mo block_for = 0Ang manggagawa ay nananatiling naka-block nang walang katiyakan hanggang sa magkaroon ng trabaho, isang bagay na dapat tandaan kung gusto mo itong tumugon nang mabilis sa mga senyales tulad ng SIGTERM o i-pause ang mga utos.

Iba pang mga driver: SQS, Beanstalkd, null, failover...

Bukod sa mga database at redis, sinusuportahan din ng Laravel ang iba pang mga sistema :

• Amazon SQSMga pinamamahalaang pila sa AWS, na may suporta para sa FIFOMga pangkat ng mensahe, deduplication, at advanced na mga setting ng visibility. Nangangailangan ng SDK. aws/aws-sdk-php.
• BeanstalkdNapakabilis at madali, gamit ang pakete pda/pheanstalk.
• i-sync: nagsasagawa ng mga gawain agad sa parehong proseso. Kapaki-pakinabang sa pag-unlad o pagsubok, ngunit sa produksyon ay halos hindi gumagamit ng mga pila.
• walang halaga: Itinatapon ang mga trabaho sa sandaling "ipinadala" ang mga ito. Ginagamit upang ganap na i-disable ang queuing system.
• failoverBinibigyang-daan ka nitong mag-configure ng maraming koneksyon, at kung nabigo ang pangunahin, susubukan ni Laravel na itulak ang trabaho sa susunod sa listahan. Perpekto para sa mga kapaligiran kung saan ang mataas na kakayahang magamit ay kritikal.

Sa antas ng pag-pause at pagpapatuloy ng mga worker, halos pareho ang lohika anuman ang driver, dahil pinamamahalaan ito mula sa mga utos ng Artisan at sa klase ng Worker , hindi mula sa queue backend.

Paglikha ng trabaho at serialization ng modelo

Un Trabaho Sa Laravel, isa lang itong klase na nagsa-encapsulate ng isang gawain na isasagawa sa isang queue. Karaniwan itong nabuo gamit ang Artisan at naka-save sa app/Jobs.

Upang lumikha ng isa:

php artisan make:job ProcessPodcast

Ang nabuong klase nagpapatupad ShouldQueue at kadalasang gumagamit ng mga katangian Dispatchable, InteractsWithQueue, Queueable y SerializesModelsAng puso ay nasa pamamaraan handle()na kung ano ang ginagawa ng manggagawa kapag dumating ang trabaho.

Isang partikular na makapangyarihang tampok ang awtomatikong serialization ng mga modelo ng Eloquent . Kung tatanggapin mo ang isang modelo sa Job constructor, hindi idinaragdag ng Laravel ang buong object sa queue, kundi ang identifier lamang nito. Kapag naproseso na ang trabaho, muling binubuo nito ang modelo mula sa database kasama ang mga relasyon nito na naka-load na.

Karaniwang halimbawa (sa pseudocode, upang maiwasang maulit ito sa verbatim):

• Natatanggap ng tagabuo Podcast $podcast.
• Ang katangian SerializesModels Responsable ito sa pag-save ng ID.
• En handle(AudioProcessor $processor) Ginagawa mo ang mahirap na trabaho (pagproseso ng audio, halimbawa).

Kung ayaw mong ma-serialize ang mga relasyon sa isang modelo (kaya hindi malaki ang payload), maaari mong gamitin $model->withoutRelations() o sa PHP 8 ang attribute # sa na-promote na ari-arian ng tagabuo.

Dependency injection sa paraan ng paghawak

Ang isa pang kalamangan ay maaari mo direktang mag-inject ng mga serbisyo sa paraan ng paghawak (parang ito ay isang controller), dahil ginagamit din ni Laravel ang lalagyan ng serbisyo sa Trabaho. Halimbawa, maaari kang humiling ng a AudioProcessorMga kliyente ng HTTP, mga repositoryo, atbp., at ang balangkas ang nangangasiwa sa paglutas sa mga ito.

Kung kailangan mo ng napakahusay na kontrol sa tinatawag na handlemaaari mong gamitin Container::bindMethod() sa isang service provider at tukuyin ang lohika ng pag-iniksyon sa iyong sarili, ngunit sa karamihan ng mga kaso ay hindi na kailangang gawing kumplikado ang mga bagay nang labis.

Middleware ng Trabaho

Kung paanong may middleware ang mga ruta, maaari ding magkaroon ang Trabaho tiyak na middleware na tumatakbo bago at pagkatapos ng trabaho. Lubos nitong binabawasan ang paulit-ulit na code sa mga pamamaraan handle() at ito ay lalong kapaki-pakinabang para sa:

• Paglilimita sa rate kasama si Redis.
• iwasan nagsasapawan ng mga gawa na nakakaapekto sa parehong mapagkukunan.
• Mga regular na pagbubukod para sa mga hindi matatag na API.
• Nilaktawan ang mga trabaho sa ilalim ng ilang partikular na kundisyon (Skip middleware).

Karaniwang inilalagay ang middleware app/Jobs/Middleware at ibinalik mula sa pamamaraan middleware() Mula kay Job. Konseptwal na halimbawa:

public function middleware(): array { return ;

Mga espesyal na uri ng trabaho: natatangi, naka-encrypt, at naka-lock

Pinapayagan ka ng Laravel na markahan ang ilang mga trabaho bilang natatangi upang matiyak na walang dalawang magkatulad na pagkakataon ang nakapila sa parehong oras. Ito ay nakamit sa pamamagitan ng pagpapatupad ng interface ShouldBeUnique o ShouldBeUniqueUntilProcessingat sumusuporta sa pagtukoy ng isang susi uniqueId() at isang oras uniqueFor.

Ito ay perpekto para sa mga bagay tulad ng:

• Muling kalkulahin ang index ng paghahanap ng produkto: isang beses lang kada produkto hanggang sa matapos ito.
• Mga pag-synchronize sa mga panlabas na serbisyo na hindi pinapayagan ang mga sabay-sabay na kahilingan para sa parehong mapagkukunan.

Sa ilalim, gumagamit si Laravel ng a atomic lock ng cache (Redis, memcached, database, atbp.). Maaari mo ring piliin ang cache driver para sa lock na iyon uniqueVia().

Bilang karagdagan, mayroong interface ShouldBeEncrypted, kung saan ipinapahiwatig mo na ang kumpletong Trabaho ay Ilagay ang iyong code bago pumasok sa pilaNapaka-kapaki-pakinabang kapag nagpapasa ng sensitibong data at hindi mo nais na maglakbay ito sa plain text sa pamamagitan ng Redis, SQS o ang database.

Mag-dispatch, mag-antala, at magsagawa ng mga trabaho sa iba't ibang mga mode

Kapag natukoy na ang iyong trabaho, ilulunsad mo ito Job::dispatch() mula sa mga controller, tagapakinig ng kaganapan, mga utos ng Artisan, o kahit na mga pagsasara. Ang mga parameter na ipapasa mo dispatch Direkta silang pumunta sa tagapagtayo ni Job.

Mga kagiliw-giliw na pagkakaiba-iba:

• dispatchIf() y dispatchUnless() upang ikondisyon ang kargamento sa isang linya.
• delay() upang ang trabaho ay hindi maproseso hanggang sa isang tiyak na petsa/oras.
• dispatchAfterResponse() o afterResponse() en dispatch() Mga pagsasara, na nagpapaliban sa pagpapatupad hanggang sa maipadala ang tugon ng HTTP, ngunit sa loob ng parehong proseso ng PHP.
• dispatchSync() upang patakbuhin ang Job nang sabay-sabay (nang hindi dumaan sa pila) ngunit muling ginagamit ang parehong klase.
• Mga espesyal na koneksyon tulad ng deferred o background upang isagawa pagkatapos ng tugon, sa parehong proseso o sa isang bagong proseso ng PHP.

Sa wakas, maaari mong tukuyin ang koneksyon at pila na may mga nakakadena na pamamaraan onConnection() y onQueue(), alinman kapag nagpapadala o sa loob ng tagabuo ng Trabaho.

Pinong kontrol: muling pagsubok, backoff, timeout, at paghawak ng error

Ang isang malaking bahagi ng paggamit ng mga pila sa Laravel ay ang pagpapasya kung ilang beses susubukan muli ang isang trabaho , gaano katagal maghihintay sa pagitan ng mga pagtatangka, at kung kailan ito ituturing na isang pagkabigo.

Magagamit na Mga Pagpipilian:

• --tries en queue:work upang itakda ang maximum na bilang ng mga pagtatangka para sa lahat ng trabaho ng manggagawang iyon (maliban kung ang Trabaho ang nagtakda ng sarili nito) $tries o tries()).
• $tries o isang pamamaraan tries() sa klase ng Job para sa bawat-Job control.
• retryUntil() para sabihin: "subukang muli hangga't gusto mo hanggang sa oras na ito, pagkatapos nito, ito ay kabiguan." Kung ito ay sumasabay sa tries, utos retryUntil.
• $maxExceptions upang putulin kapag ang problema ay dahil sa paulit-ulit na hindi nahawakang mga pagbubukod.
• $timeout o --timeout upang ipahiwatig kung ilang segundo ang maaaring tumakbo ng isang Trabaho bago patayin ng manggagawa ang proseso ng bata.
• $failOnTimeout upang markahan ang trabaho bilang nabigo kung sakaling mag-timeout.
• $backoff ang pamamaraan backoff() upang tukuyin kung gaano katagal maghihintay sa pagitan ng mga muling pagsubok, kahit na may mga exponential value.

Kung ang isang trabaho ay naghagis ng hindi nahuhuling pagbubukod, si Laravel ay... naglalabas pabalik sa buntot hanggang sa maubos ang na-configure na mga pagtatangka. Maaari mong kontrolin ito nang manu-mano gamit ang release($segundos) o fail($exception) kapag gusto mong sadyang markahan ang isang trabaho bilang nabigo.

Mga bigong trabaho, failed_jobs table at pruning

Kapag ang isang Job ay naubos ang kanyang mga pagtatangka, siya ay naiisip bagsak na trabaho at ipinasok ito ni Laravel sa mesa failed_jobs (o sa DynamoDB kung i-configure mo ito sa ganoong paraan). Ang talahanayan na iyon ay nag-iimbak ng UUID, koneksyon, pila, kargamento ng trabaho, at ang pagbubukod na itinapon.

Mga kapaki-pakinabang na utos:

• php artisan queue:failed upang ilista ang mga nabigo.
• php artisan queue:retry <id|all> upang subukang muli ang mga ito.
• php artisan queue:forget <id> para tanggalin ang isa.
• php artisan queue:flush upang tanggalin ang lahat (na may opsyon para sa mga oras sa mas bagong bersyon).
• php artisan queue:prune-failed --hours=48 upang awtomatikong putulin ang mga lumang tala.

Sa Trabaho maaari mong tukuyin ang isang paraan failed(Throwable $exception) Para sa dagdag na paglilinis: abisuhan ang user, ibalik ang mga bahagyang pagkilos, magsulat ng mga espesyal na log, atbp. Tandaan na ang isang bagong instance ng Trabaho ay ginawa upang tumawag failed()Samakatuwid, huwag umasa sa mga pagbabago sa ari-arian na ginawa sa handle().

Job batching: batch ng mga trabaho at pagsasama-sama ng mga ito sa mga string

Kapag kailangan mong maglunsad ng daan-daan o libu-libong kaugnay na trabaho (halimbawa, pag-import ng isang malaking CSV nang paunti-unti, pagproseso ng mga file nang batch, paglilinis ng data, atbp.), ipinapayong gamitin ang batch functionality ng Laravel .

Pangunahing daloy:

• Lumikha ng talahanayan job_batches sa php artisan queue:batches-table && php artisan migrate.
• Markahan ang Mga Trabaho na magiging bahagi ng mga batch na may katangian Batchable.
• Gamitin Bus::batch() upang magpadala ng isang hanay ng mga Trabaho, na may mga callback then, catch y finally.
• I-access ang batch mula sa bawat Trabaho na may $this->batch() at tingnan kung nakansela ito.
• Posibilidad na magdagdag ng higit pang Mga Trabaho sa isang patuloy na batch na may $this->batch()->add().

Ang mga batch ay mahusay na nagsasama sa mga chain : maaari kang magkaroon ng mga chain sa loob ng isang batch o mga batch bilang mga elemento ng isang mas malaking chain. Ito ay lalong kapaki-pakinabang kapag gusto mong tumakbo ang maraming chain "nang sabay-sabay" at mag-trigger ng isang bagay kapag nakumpleto na ang lahat.

Pagpapatupad ng manggagawa, mga priyoridad, at pag-deploy

Ang lahat ng mahika ng mga pila ay nangyayari dahil mayroon ka isa o higit pang manggagawa tumatakbo ang utos queue:work (o queue:listen(bagaman ang huli ay hindi gaanong mahusay). Ang mga prosesong ito ay mga daemon na matagal nang nakikinig sa kani-kanilang mga pila.

Mga pangunahing opsyon ng queue:work:

• Koneksyon: php artisan queue:work redis, queue:work database, Atbp
• Colas: --queue=high,default,low upang unahin.
• -labing-isa: nagpoproseso ng isang trabaho at paglabas.
• –max-trabaho: nagpoproseso ng mga X na trabaho at nagwawakas (para pana-panahong i-restart ang mga manggagawa at palayain ang memorya).
• –max-time: mga proseso ng N segundo at pagkatapos ay lalabas.
• – tulog: segundo ng paghihintay kapag walang available na trabaho.
• –tumigil-kapag-walang laman: walang laman ang pila at nagsasara ng malinis (perpekto sa mga kapaligiran ng Docker o mga one-off na trabaho).
• –timeout: segundo ng timeout sa bawat trabaho, tulad ng nabanggit namin dati.
• -Pagtatanggol: upang iproseso ang mga trabaho kahit na ang app ay nasa maintenance mode.

Dahil ang mga prosesong ito ay matagal nang tumatakbo, sa produksyon, ang isang process monitor tulad ng Supervisor (sa Linux) ay halos palaging ginagamit upang simulan ang mga X worker, i-restart ang mga ito kung sakaling mag-crash, at pamahalaan ang mga log. Ang isang tipikal na Supervisor configuration block para sa Laravel ay tumutukoy sa:

• utos sa php artisan queue:work ... kongkreto.
• nuprocs upang ipahiwatig kung gaano karaming mga manggagawa ang ilulunsad nang magkatulad.
• Log path, user, awtomatikong pag-restart, atbp.

Paghinto at pagpapatuloy ng mga pila sa Laravel

Talakayin natin kung ano ang kadalasang mahalaga sa maintenance: kung paano i-pause ang mga queue worker nang hindi sila biglang pinahihinto at hindi iniiwan ang mga trabahong hindi natapos. Nag-aalok ang Laravel ng ilang mekanismo, ang ilan ay mas bago, ang ilan ay klasiko, upang makontrol ito.

I-pause: queue:pause at interrupt ang mga signal

Sa mga kamakailang bersyon, nagdadagdag ang Laravel ng mga partikular na utos upang i-pause at ipagpatuloy ang pagpapatupad ng mga manggagawa:

• php artisan queue:pause: nagsasabi sa system na huminto sa pagkuha ng mga bagong trabaho, ngunit hayaang matapos ang mga kasalukuyang ginagawa.
• php artisan queue:continue: nagpapatuloy sa pagproseso ng mga bagong trabaho mula sa kung saan ito tumigil.

Ang mga utos na ito ay gumagana sa pamamagitan ng pagpapadala ng mga signal sa mga worker sa pamamagitan ng mekanismo ng caching na ginagamit ng Laravel sa loob. Kaya naman mahalagang magkaroon ng maayos na na-configure na cache driver (memcached, redis, database, file, atbp.) kahit na ang iyong aktwal na cache queue ay iba.

Mahalaga: Ang pag-pause ng isang pila o manggagawa ay hindi nagkakansela o nagtatanggal ng mga trabahong nakapila na ; pinipigilan lamang nito ang pag-alis ng higit pang mga trabaho mula sa pila habang tumatagal ang pag-pause.

Pagboto ng mga pagkagambala at epekto sa pagganap

Sa tuwing natatapos ng isang manggagawa ang isang trabaho, sinusuri ng Laravel ang cache para sa mga signal ng pag-restart, pag-pause, o pagpapatuloy . Maliit lang ang gastos nito, ngunit umiiral ito. Kung labis kang nakatutok sa pagganap at alam mong hindi mo na kailangang i-pause o i-restart ang mga manggagawa mula sa mga utos, maaari mong i-disable ang polling na ito sa pamamagitan ng pagtawag sa:

Queue::withoutInterruptionPolling();

O kahit na ayusin ang mga static na katangian ng Illuminate\Queue\Worker upang huwag paganahin ang mga partikular na pagpindot ($restartable, $pausableGayunpaman, kung gagawin mo ito at pagkatapos ay subukang gamitin queue:pause o queue:restartang mga manggagawa Hindi nila malalamanIsa itong desisyon sa disenyo na dapat pag-isipang mabuti.

I-pause nang manu-mano gamit ang Supervisor o Docker

Bukod sa mga utos mismo ng Laravel , sa mga kapaligiran ng produksyon, ang mga proseso ay kadalasang "nakahinto" nang hindi direkta:

• Paghinto ng programa sa Supervisor (supervisorctl stop laravel-worker:*), na pumapatay o humihinto sa mga manggagawa.
• paggamit –tumigil-kapag-walang laman sa mga deployment upang hayaan ang mga manggagawa na tapusin kung ano ang nasa pila at pagkatapos ay isara.
• Sa Docker, hinahayaan ang container na iproseso ang --stop-when-empty at pagkatapos ay naka-off ito.

Ang pagkakaiba sa queue:pause Sa ganap na pagpapahinto sa mga proseso, ititigil mo ang pagpoproseso ng mga trabaho hanggang sa mag-restart ang mga manggagawa. panloob na paghinto Maaari mong panatilihin ang mga proseso sa memorya, naghihintay para sa utos continueIto ay kapaki-pakinabang para sa mabilis na roll-back deployment o maikling panahon ng pagpapanatili.

Mga transaksyon sa database at after_commit

Isang klasikong pagkakamali: pagpapadala ng mga trabaho sa loob ng mga transaksyon sa database . Kung hindi ka mag-iingat, maaaring isagawa ng worker ang trabaho bago pa magawa ang commit, at ang modelo o datos na iyong inaasahan ay maaaring wala pa sa database.

Upang maiwasan ang sayaw na ito, mayroon kang dalawang pagpipilian:

• Aktibahin 'after_commit' => true sa configuration ng koneksyon sa pila. Kaya, anumang Trabaho na ipinadala sa loob ng isang transaksyon ay ipinagpaliban sa loob hanggang sa ito ay makumpirma.
• Gumamit ng mga pamamaraan sa bawat trabaho afterCommit() o beforeCommit() kapag nagpapadala, upang pilitin ang pag-uugali lamang sa mga partikular na Trabaho.

Kung ang transaksyon ay nabaligtad, ang mga trabahong ipinadala habang isinasagawa ito ay itinatapon nang hindi na pumapasok sa pila, na siyang tiyak na ninanais upang mapanatili ang pagkakapare-pareho.

Pagsubaybay, paglilinis ng pila, at pagsubok

Kapag nakapila na nang maayos, hindi sapat na basta na lang kalimutan ang mga Trabaho; dapat mong subaybayan at subukan kung paano gumagana ang lahat.

Mga kapaki-pakinabang na tool at utos:

• queue:clear upang walang laman ang isang partikular na pila (SQS, Redis, database).
• queue:monitor upang subaybayan ang bilang ng mga trabaho sa ilang partikular na pila at ma-trigger ang kaganapan QueueBusy kung lumampas sila sa isang threshold.
• Mga Kaganapan sa Trabaho bilang Queue::before, Queue::after, Queue::looping y Queue::failing para i-hook ang custom na logic (mga log, sukatan, rollback, atbp.).
• Mga peke sa pagsubok paggamit Queue::fake() y Bus::fake() upang i-verify na ang Mga Trabaho, string o batch ay naipadala nang hindi aktwal na isinasagawa ang mga ito.

Sa mga pagsubok, maaari mong sabihin ang mga bagay tulad ng "ang Trabahong ito ay na-queue nang X beses" , "isang chain na may mga Trabahong ito ang naipadala sa ganitong pagkakasunud-sunod" o "walang partikular na Trabahong na-queue", na nagbibigay ng maraming seguridad sa mga kumplikadong daloy.

Sa buong ecosystem na ito—mga driver tulad ng Redis o SQS, mga trabahong mahusay na idinisenyo, middleware para sa fine-tuning, mga batch, chain, muling pag-configure, mga manggagawang pinamamahalaan ng Supervisor, at mga command tulad ng queue:pause y queue:continue— Hinahayaan ka ng Laravel na ma-master ang pagpoproseso ng background hanggang sa milimetro, mula sa karaniwang pagpapadala ng email sa mga distributed queue architecture na may failover, na tinitiyak na patuloy na tumutugon ang iyong application sa HTTP layer habang ang mabibigat na trabaho ay ginagawa sa ilalim nang hindi hinaharangan ang user.