Queuety
Il motore di flussi di lavoro WordPress.
wp plugin install https://github.com/inline0/queuety/releases/latest/download/queuety.zip --activateUltima versione 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!',
] );Nella pratica
Un flusso di lavoro definito in PHP e il comando worker che lo esegue.
Un flusso di approvazione
Il flusso di lavoro esegue un passaggio, attende 24 ore, poi si sospende su wait_for_approval() finché un altro processo non invia il segnale approval.
Il ritardo viene salvato nel database, quindi persiste anche dopo il riavvio dei worker e le distribuzioni; inoltre, un segnale inviato in anticipo viene registrato e ricevuto quando il flusso di lavoro raggiunge l'attesa. L'annullamento dell'esecuzione chiama il gestore 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=6Claim diretti su MySQL
Ogni worker viene eseguito in un processo WP-CLI a lunga durata e preleva i job direttamente da MySQL con FOR UPDATE SKIP LOCKED.
Flussi di lavoro durevoli
Processi articolati in più passaggi con stato persistente, che sopravvive ai timeout, agli arresti anomali e ai nuovi tentativi di PHP.
Macchine a stati
Stato attivato da eventi e di lunga durata con Queuety::machine(): definite stati e transizioni, inviate eventi e consultate la cronologia.
Segnali e approvazioni
wait_for_signal(), wait_for_approval() e wait_for_input() sospendono un flusso di lavoro finché non arriva un input esterno.
Livelli di priorità
Quattro livelli, da bassa a urgente. All'interno di una coda, i job con priorità più alta vengono prelevati per primi.
Limitazione della frequenza
Limiti per gestore su una finestra mobile. Un worker che preleva un job soggetto a limiti di frequenza lo rimette in coda e attende.
Job ricorrenti
Pianificazione basata su intervalli e su cron. Parser cron integrato, senza dipendenze esterne.
Passaggi paralleli
Eseguite contemporaneamente i passaggi del flusso di lavoro e attendete che siano tutti completati prima di proseguire.
Metriche e log
Un log permanente nel database con throughput, durata media e p95 e tasso di errore per gestore.
Fallback WP-Cron
Senza accesso alla shell, un evento WordPress cron al minuto avvia un worker monouso per la coda predefinita.
Middleware
Middleware per job in stile onion, con limiti di frequenza, limitazione delle eccezioni, unicità, timeout e protezione dalle sovrapposizioni.
PHP 8.2+
Enum, classi readonly, espressioni match, promozione dei parametri nel costruttore e attributi PHP.
Perché Queuety
Lo stato risiede in MySQL
Le righe della coda, lo stato del flusso di lavoro, i log, i segnali e i blocchi trasmessi vengono archiviati in MySQL, quindi il riavvio di un worker non perde lo stato di orchestrazione. Ogni passaggio registra in un'unica transazione l'aggiornamento dello stato, il completamento del job e l'accodamento di quello successivo.
Fuori dalla richiesta della pagina
WP-Cron si attiva solo quando si visitano le pagine e una chiamata LLM di 60 secondi viene interrotta dal timeout PHP di 30 secondi. I worker Queuety vengono eseguiti in un processo WP-CLI di lunga durata e acquisiscono i job senza attendere il traffico.
Garanzie per le esecuzioni degli agenti
for_each() con modalità a quorum, punti di approvazione e limiti come max_transitions() e max_state_bytes() mantengono le esecuzioni prolungate degli agenti entro limiti definiti.
Utilizzabile al di fuori di WordPress
Il nucleo basato sul database funziona in qualsiasi processo PHP in grado di connettersi allo stesso database; un'altra app può quindi avviare job, inviare segnali e leggere lo stato del flusso di lavoro. I trigger delle azioni, il bridge WP-Cron e i comandi WP-CLI richiedono comunque WordPress.
A confronto con
Come Queuety si integra con gli scheduler e i motori di flussi di lavoro che gli sviluppatori WordPress già conoscono.
| Strumento | Ideale per | Differenze rispetto a Queuety |
|---|---|---|
| WP-Cron | Ideale perIntegrato in WordPress, non richiede accesso allo scheduler di sistema sugli hosting condivisi; inoltre, un'attività che non viene eseguita all'ora prevista parte al caricamento successivo della pagina, invece di essere scartata. | Differenze rispetto a QueuetyI worker Queuety vengono eseguiti indipendentemente dal traffico del sito e richiedono un processo wp queuety work di lunga durata. Il bridge WP-Cron trasforma gli eventi ricorrenti in pianificazioni, ma per ora non esegue i relativi callback degli hook, quindi WP-Cron continua a gestirli. |
| Action Scheduler | Ideale perProgettato per la distribuzione nei plugin e nei temi, senza richiedere accesso al server; ogni mese elabora milioni di pagamenti per gli abbonamenti e webhook per WooCommerce, registrando ogni azione in un'interfaccia di amministrazione. | Differenze rispetto a QueuetyAction Scheduler esegue un hook più tardi, come un do_action() ritardato. Queuety aggiunge flussi di lavoro articolati in più passaggi con stato persistente tra un passaggio e l'altro, attese di segnali e approvazioni e macchine a stati; potete consultarli tramite comandi WP-CLI come wp queuety workflow timeline. |
| Temporal | Ideale perUna piattaforma di esecuzione durevole: Event History registra ogni passaggio di un flusso di lavoro, consentendo di riprendere l'esecuzione dall'ultimo evento registrato dopo arresti anomali o interruzioni; Temporal Cloud è disponibile in alternativa all'hosting autonomo del servizio. | Differenze rispetto a QueuetyUn servizio Temporal è un server Go con un database, eseguito accanto all'applicazione. Queuety conserva lo stato nelle tabelle MySQL sulla connessione al database WordPress ed esegue i worker tramite WP-CLI. |
Domande e risposte
Risposte brevi dalla documentazione di Queuety.
Non per le operazioni semplici nella coda predefinita. Il plugin esegue un worker una tantum tramite WordPress cron ogni minuto, purché WordPress cron sia attivo, e gestisce un job per esecuzione. Le pianificazioni ricorrenti, le code personalizzate e una latenza inferiore richiedono un processo wp queuety work dedicato.
No. Richiede mysqli oppure pdo_mysql e per impostazione predefinita sceglie mysqli in WordPress. Definite QUEUETY_DB_DRIVER come auto, mysqli o pdo per forzare l'uso di un driver.
I job vengono acquisiti con SELECT ... FOR UPDATE SKIP LOCKED, supportato da MySQL dalla versione 8.0 e da MariaDB dalla 10.6. La CI del progetto viene eseguita su MySQL 8.0.
Sì. Il nucleo basato sul database, che comprende job, worker, flussi di lavoro, segnali, macchine a stati, artefatti, log, metriche e pianificazioni, funziona con una connessione diretta. I pool di worker richiedono anche le costanti DB_HOST, DB_NAME, DB_USER e DB_PASSWORD. Queuety::on_action(), replace_wp_cron(), l'inizializzazione del plugin e i comandi wp queuety richiedono comunque WordPress.
Non ancora. Queuety::replace_wp_cron() converte gli eventi ricorrenti di wp_schedule_event() in pianificazioni Queuety, ma i callback degli hook non vengono ancora eseguiti; continuate quindi a usare WP-Cron per gli eventi che devono essere attivati. Gli eventi di wp_schedule_single_event() restano gestiti da WP-Cron.
wp queuety work --workers=N crea un pool fisso di processi e riavvia quelli che si arrestano; richiede le estensioni pcntl e posix. --min-workers e --max-workers creano un pool adattivo che aumenta con gli arretrati e si riduce quando l'attività rallenta.
Installate il plugin, avviate un worker e seguite le guide: dal primo job ai flussi di lavoro con approvazioni e alle macchine a stati.