Queuety
WordPress-workflowmotoren.
wp plugin install https://github.com/inline0/queuety/releases/latest/download/queuety.zip --activateSeneste udgivelse v0.22.0 GPL-2.0-or-later WordPress 6.4+, PHP 8.2+
use Queuety\Queuety;
Queuety::register( 'send_email', SendEmailHandler::class );
Queuety::dispatch( 'send_email', [
'to' => 'user@example.com',
'subject' => 'Welcome',
'body' => 'Hello from Queuety!',
] );I praksis
Et workflow defineret i PHP og worker-kommandoen, der kører det.
Et godkendelsesworkflow
Workflowet udfører et trin, venter 24 timer og sættes derefter på pause ved wait_for_approval(), indtil en anden proces sender signalet approval.
Forsinkelsen gemmes i databasen, så den overlever genstart af workeren og udrulninger, og et signal, der sendes tidligt, registreres og opfanges, når workflowet når ventepunktet. Hvis kørslen annulleres, kaldes handleren on_cancel().
$workflow_id = Queuety::workflow( 'approval_flow' )
->then( SubmitRequestHandler::class )
->delay( hours: 24 )
->wait_for_approval()
->then( ProcessApprovalHandler::class )
->on_cancel( CleanupHandler::class )
->dispatch( [ 'request_id' => 99 ] );
// Later, from another process:
Queuety::signal( $workflow_id, 'approval', [ 'approved_by' => 'admin@example.com' ] );# Single worker on default queue
wp queuety work
# Process a specific queue
wp queuety work --queue=emails
# Process multiple queues in priority order
wp queuety work --queue=critical,default,low
# One-shot mode
wp queuety work --once
# Multi-worker mode
wp queuety work --workers=4
# Adaptive worker pool
wp queuety work --queue=providers --min-workers=2 --max-workers=6Direkte MySQL-krav
Hver worker kører som en langvarig WP-CLI-proces og henter jobs direkte fra MySQL med FOR UPDATE SKIP LOCKED.
Robuste workflows
Processer med flere trin og vedvarende tilstand, der overlever PHP-timeouts, nedbrud og nye forsøg.
Tilstandsmaskiner
Langvarig, hændelsesdrevet tilstand med Queuety::machine(): definér tilstande og overgange, send hændelser, og læs tidslinjen.
Signaler og godkendelser
wait_for_signal(), wait_for_approval() og wait_for_input() sætter et workflow på pause, indtil der modtages eksternt input.
Prioritetsniveauer
Fire niveauer fra lav til akut. I en kø hentes jobs med højere prioritet først.
Hastighedsbegrænsning
Grænser pr. handler over et glidende tidsvindue. En worker, der henter et hastighedsbegrænset job, lægger det tilbage og venter.
Tilbagevendende jobs
Planlægning baseret på intervaller og cron. Indbygget cron-parser uden eksterne afhængigheder.
Parallelle trin
Kør workflowtrin samtidigt, og vent på, at alle er færdige, før du fortsætter.
Målinger og logning
En permanent databaselog med gennemløb, gennemsnitlig varighed og p95-varighed samt fejlfrekvens pr. handler.
WP-Cron-reservefunktion
Uden shelladgang starter en WordPress-cron-hændelse én gang i minuttet en engangs-worker for standardkøen.
Middleware
Onion-lignende job-middleware til hastighedsbegrænsninger, begrænsning af undtagelser, entydighed, timeouts og beskyttelse mod overlap.
PHP 8.2+
Enums, skrivebeskyttede klasser, match-udtryk, konstruktørpromovering og attributter i PHP.
Hvorfor Queuety
Tilstanden ligger i MySQL
Kørækker, workflowtilstand, logfiler, signaler og streamede chunks gemmes i MySQL, så en genstart af workeren ikke medfører tab af orkestreringstilstand. Ved hvert trinsskift gemmes tilstandsopdateringen, jobafslutningen og den næste køplacering i én transaktion.
Uden for sideanmodningen
WP-Cron kører kun ved sidebesøg, og et 60 sekunders LLM-kald afbrydes af en timeout på 30 sekunder i PHP. Queuety-workere kører i en langvarig WP-CLI-proces og tager fat på arbejdet uden at vente på trafik.
Sikkerhedsrammer for agentkørsler
for_each() med en kvorumtilstand, godkendelsesporte og grænser som max_transitions() og max_state_bytes() holder lange agentkørsler inden for fastlagte rammer.
Kan bruges uden for WordPress
Den databasebaserede kerne kører i enhver PHP-proces, der kan oprette forbindelse til den samme database, så en anden app kan starte jobs, sende signaler og læse workflowstatus. Handlingsudløsere, WP-Cron-broen og kommandoerne WP-CLI kræver stadig WordPress.
Sammenlignet med
Sådan hænger Queuety sammen med de planlæggere og workflowmotorer, som WordPress-udviklere allerede kender.
| Værktøj | God til | Forskel fra Queuety |
|---|---|---|
| WP-Cron | God tilIndbygget i WordPress kræver det ikke adgang til systemets planlægger på delt hosting, og en opgave, der overskrider sin planlagte tid, køres ved næste sideindlæsning i stedet for at blive droppet. | Forskel fra QueuetyQueuety-workere kører uafhængigt af trafikken på webstedet og kræver en langvarigt kørende wp queuety work-proces. Dets WP-Cron-bro omsætter tilbagevendende hændelser til tidsplaner, men kører endnu ikke deres hook-callbacks, så WP-Cron står fortsat for dem. |
| Action Scheduler | God tilUdviklet til distribution i plugins og temaer uden behov for serveradgang. Det behandler hver måned millioner af betalinger for Subscriptions og webhooks for WooCommerce og logger alle handlinger i en administrationsgrænseflade. | Forskel fra QueuetyAction Scheduler kører et hook på et senere tidspunkt, som en forsinket do_action(). Queuety tilføjer workflows med flere trin, hvor tilstanden bevares mellem trinnene, ventepunkter for signaler og godkendelser samt tilstandsmaskiner. Du kan undersøge dem med WP-CLI-kommandoer som wp queuety workflow timeline. |
| Temporal | God tilEn platform til robust eksekvering: En hændelseshistorik registrerer hvert trin i et workflow, så en kørsel kan fortsætte fra den senest registrerede hændelse efter nedbrud eller afbrydelser. Temporal Cloud tilbydes som et alternativ til selv at hoste tjenesten. | Forskel fra QueuetyEn Temporal-tjeneste er en Go-server plus en database, der kører ved siden af din applikation. Queuety gemmer sin tilstand i MySQL-tabeller på databaseforbindelsen WordPress og kører workere gennem WP-CLI. |
Spørgsmål og svar
Korte svar fra Queuety-dokumentationen.
Ikke for enkle jobs i standardkøen. Pluginnet starter en engangs-worker via WordPress cron hvert minut, så længe WordPress cron kører, og den håndterer ét job pr. kørsel. Tilbagevendende tidsplaner, brugerdefinerede køer og lavere latenstid kræver en dedikeret wp queuety work-proces.
Nej. Det kræver enten mysqli eller pdo_mysql og vælger som standard mysqli under WordPress. Definér QUEUETY_DB_DRIVER som auto, mysqli eller pdo for at gennemtvinge en driver.
Jobs hentes med SELECT ... FOR UPDATE SKIP LOCKED, som MySQL understøtter fra version 8.0 og MariaDB fra version 10.6. Projektets CI kører mod MySQL 8.0.
Ja, den databasebaserede kerne: jobs, workere, workflows, signaler, tilstandsmaskiner, artefakter, logfiler, målinger og tidsplaner kører via en direkte Connection. Worker-pools kræver også konstanterne DB_HOST, DB_NAME, DB_USER og DB_PASSWORD. Queuety::on_action(), replace_wp_cron(), plugin-bootstrap og kommandoerne wp queuety kræver stadig WordPress.
Ikke endnu. Queuety::replace_wp_cron() omsætter tilbagevendende hændelser fra wp_schedule_event() til Queuety-tidsplaner, men deres hook-callbacks køres endnu ikke, så behold WP-Cron til hændelser, der skal udløses. Hændelser fra wp_schedule_single_event() håndteres fortsat af WP-Cron.
wp queuety work --workers=N forgrener en fast pulje og genstarter børn, der går ned; det kræver udvidelserne pcntl og posix. --min-workers og --max-workers kører en adaptiv pulje, der vokser med efterslæbet og skrumper, når der bliver mindre at lave.
Installer pluginnet, start en worker, og følg vejledningerne fra dit første job til godkendelsesforløb og tilstandsmaskiner.