Queuety
Le moteur de workflow WordPress.
wp plugin install https://github.com/inline0/queuety/releases/latest/download/queuety.zip --activateDernière version 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!',
] );En pratique
Un workflow défini dans PHP et la commande worker qui l’exécute.
Un workflow d’approbation
Le workflow exécute une étape, attend 24 heures, puis se met en pause à wait_for_approval() jusqu’à ce qu’un autre processus envoie le signal approval.
Le délai est stocké dans la base de données ; il résiste donc aux redémarrages des workers et aux déploiements. Un signal envoyé à l’avance est enregistré et pris en compte lorsque le workflow atteint l’attente. L’annulation de l’exécution appelle le gestionnaire 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=6Prise en charge directe des revendications MySQL
Chaque worker s’exécute dans un processus WP-CLI de longue durée et récupère directement les tâches depuis MySQL avec FOR UPDATE SKIP LOCKED.
Workflows durables
Processus à plusieurs étapes avec un état persistant qui résiste aux délais d’attente PHP, aux plantages et aux nouvelles tentatives.
Machines à états
État événementiel de longue durée avec Queuety::machine() : définissez des états et des transitions, envoyez des événements et consultez la chronologie.
Signaux et approbations
wait_for_signal(), wait_for_approval() et wait_for_input() mettent un workflow en pause jusqu’à la réception d’une entrée externe.
Niveaux de priorité
Quatre niveaux, de Faible à Urgent. Dans une file d’attente, les tâches prioritaires sont récupérées en premier.
Limitation du débit
Limites par gestionnaire sur une fenêtre glissante. Un worker qui récupère une tâche limitée par le débit la remet en file d’attente et attend.
Tâches récurrentes
Planification par intervalle et selon cron. Analyseur cron intégré, sans dépendances externes.
Étapes parallèles
Exécutez les étapes du workflow en parallèle et attendez qu’elles soient toutes terminées avant de poursuivre.
Métriques et journalisation
Journal permanent en base de données avec le débit, la durée moyenne et au 95e percentile, ainsi que le taux d’erreur par gestionnaire.
Relais WP-Cron
Sans accès au shell, un événement WordPress cron lancé une fois par minute exécute un worker ponctuel pour la file d’attente par défaut.
Intergiciel
Intergiciel de tâches en couches pour gérer les limites de débit, la limitation des exceptions, l’unicité, les délais d’attente et la prévention des chevauchements.
PHP 8.2+
Énumérations, classes en lecture seule, expressions match, promotion de constructeur et attributs PHP.
Pourquoi Queuety
L’état est stocké dans MySQL
Les lignes de la file d’attente, l’état des workflows, les journaux, les signaux et les segments diffusés sont stockés dans MySQL ; un redémarrage du worker ne fait donc perdre aucun état d’orchestration. À chaque fin d’étape, la mise à jour de l’état, la fin de la tâche et la mise en file d’attente de la suivante sont validées dans une même transaction.
En dehors de la requête de page
WP-Cron ne se déclenche qu’à la visite d’une page, et un appel LLM de 60 secondes est interrompu par un délai d’attente PHP de 30 secondes. Les workers Queuety s’exécutent dans un processus WP-CLI de longue durée et prennent en charge les tâches sans attendre le trafic.
Garde-fous pour les exécutions d’agents
for_each() avec un mode quorum, des étapes d’approbation et des limites telles que max_transitions() et max_state_bytes() maintiennent les longues exécutions d’agents dans un cadre défini.
Utilisable en dehors de WordPress
Le cœur basé sur une base de données s’exécute dans tout processus PHP pouvant se connecter à la même base de données. Une autre application peut donc distribuer des tâches, envoyer des signaux et consulter l’état des workflows. Les déclencheurs d’action, le pont WP-Cron et les commandes WP-CLI nécessitent toujours WordPress.
Comparaison avec
Comment Queuety s’intègre aux planificateurs et moteurs de workflow que les développeurs WordPress connaissent déjà.
| Outil | Idéal pour | Différence avec Queuety |
|---|---|---|
| WP-Cron | Idéal pourIntégré à WordPress, il ne nécessite aucun accès au planificateur système sur un hébergement mutualisé. Une tâche manquée s’exécute au prochain chargement de page au lieu d’être abandonnée. | Différence avec QueuetyLes workers Queuety fonctionnent indépendamment du trafic du site et nécessitent un processus wp queuety work de longue durée. Son pont WP-Cron transforme les événements récurrents en planifications, mais n’exécute pas encore leurs callbacks de hook ; WP-Cron reste donc chargé de les exécuter. |
| Action Scheduler | Idéal pourConçu pour être distribué dans des plugins et des thèmes sans accès au serveur, il traite chaque mois des millions de paiements pour les abonnements et de webhooks pour WooCommerce, et consigne chaque action dans une interface d’administration. | Différence avec QueuetyAction Scheduler exécute un hook ultérieurement, comme un do_action() différé. Queuety ajoute des workflows en plusieurs étapes dont l’état persiste entre les étapes, des attentes de signal et d’approbation, ainsi que des machines à états. Vous pouvez les inspecter à l’aide de commandes WP-CLI comme wp queuety workflow timeline. |
| Temporal | Idéal pourUne plateforme d’exécution durable : un historique des événements consigne chaque étape d’un workflow. Après un plantage ou une interruption, l’exécution reprend à partir du dernier événement enregistré. Temporal Cloud est proposé comme solution de remplacement à l’hébergement du service par vos soins. | Différence avec QueuetyUn service Temporal est un serveur Go et une base de données qui s’exécutent à côté de votre application. Queuety stocke son état dans des tables MySQL sur la connexion à la base de données WordPress et exécute les workers via WP-CLI. |
Questions et réponses
Réponses courtes issues de la documentation de Queuety.
Pas pour les tâches simples dans la file d’attente par défaut. Le plugin lance un worker ponctuel via WordPress cron chaque minute, tant que WordPress cron se déclenche, et traite une tâche par exécution. Les planifications récurrentes, les files d’attente personnalisées et une latence réduite nécessitent un processus wp queuety work dédié.
Non. Il nécessite mysqli ou pdo_mysql et utilise mysqli par défaut sous WordPress. Définissez QUEUETY_DB_DRIVER sur auto, mysqli ou pdo pour imposer un pilote.
Les tâches sont récupérées avec SELECT ... FOR UPDATE SKIP LOCKED, pris en charge par MySQL à partir de la version 8.0 et par MariaDB à partir de la version 10.6. L’intégration continue du projet s’exécute avec MySQL 8.0.
Oui, le cœur basé sur une base de données — tâches, workers, workflows, signaux, machines à états, artefacts, journaux, métriques et planifications — fonctionne avec une connexion directe. Les pools de workers nécessitent également les constantes DB_HOST, DB_NAME, DB_USER et DB_PASSWORD. Queuety::on_action(), replace_wp_cron(), l’initialisation du plugin et les commandes wp queuety nécessitent toujours WordPress.
Pas encore. Queuety::replace_wp_cron() convertit les événements récurrents de wp_schedule_event() en planifications Queuety, mais leurs callbacks de hook ne s’exécutent pas encore. Conservez donc WP-Cron pour les événements qui doivent se déclencher. Les événements de wp_schedule_single_event() restent gérés par WP-Cron.
wp queuety work --workers=N crée un pool fixe et redémarre les processus enfants qui plantent ; les extensions pcntl et posix sont nécessaires. --min-workers et --max-workers créent un pool adaptatif qui s’agrandit quand le retard s’accumule et se réduit quand l’activité ralentit.
Installez le plugin, lancez un worker et suivez les guides, de votre première tâche aux workflows d’approbation et aux machines à états.