Queuety
A WordPress munkafolyamat-motor.
wp plugin install https://github.com/inline0/queuety/releases/latest/download/queuety.zip --activateLegújabb kiadás 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!',
] );A gyakorlatban
Egy PHP-ban meghatározott munkafolyamat és az azt futtató munkafolyamat-kezelő parancsa.
Jóváhagyási munkafolyamat
A munkafolyamat végrehajt egy lépést, 24 órát vár, majd szünetel a wait_for_approval() ponton, amíg egy másik folyamat el nem küldi a approval jelet.
A késleltetés az adatbázisban tárolódik, így a munkafolyamat-kezelő újraindítását és a telepítéseket is túléli. A korán küldött jel rögzítésre kerül, és a rendszer felveszi, amikor a munkafolyamat eléri a várakozási pontot. A futás megszakításakor meghívódik a on_cancel() kezelő.
$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=6Közvetlen MySQL-igénylés
Minden munkafolyamat-kezelő hosszú élettartamú WP-CLI folyamatban fut, és közvetlenül a MySQL adatbázisból igényel feladatokat a FOR UPDATE SKIP LOCKED használatával.
Tartós munkafolyamatok
Többlépéses folyamatok tartós állapottal, amelyek túlélik az PHP időtúllépéseit, összeomlásait és újrapróbálkozásait.
Állapotgépek
Hosszan futó, eseményvezérelt állapot a Queuety::machine() segítségével: állapotok és átmenetek meghatározása, események küldése, idővonal megtekintése.
Jelek és jóváhagyások
A wait_for_signal(), a wait_for_approval() és a wait_for_input() szünetelteti a munkafolyamatot, amíg külső bemenet nem érkezik.
Prioritási szintek
Négy szint az alacsonytól a sürgősig. Egy várólistán belül először a magasabb prioritású feladatokat veszi fel a rendszer.
Sebességkorlátozás
Kezelőnkénti korlátok egy gördülő időablakban. Ha egy munkafolyamat-kezelő sebességkorlátozott feladatot vesz fel, visszateszi, majd várakozik.
Ismétlődő feladatok
Időközönkénti és cron-alapú ütemezés. Beépített cron-elemző, külső függőségek nélkül.
Párhuzamos lépések
A munkafolyamat lépéseinek párhuzamos futtatása, majd várakozás mindegyik befejezéséig a továbblépés előtt.
Mérőszámok és naplózás
Állandó adatbázis-napló kezelőnkénti átviteli sebességgel, átlagos és p95 időtartammal, valamint hibaaránnyal.
WP-Cron-tartalékmegoldás
Parancsértelmező-hozzáférés nélkül egy percenként futó WordPress cron esemény egyszeri munkafolyamat-kezelőt indít az alapértelmezett várólistához.
Middleware
Hagymamodellű feladatköztes réteg sebességkorlátokhoz, kivételkezelés szabályozásához, egyediséghez, időtúllépésekhez és párhuzamos futás elleni védelemhez.
PHP 8.2+
Felsorolástípusok, csak olvasható osztályok, match kifejezések, konstruktorpromóció és PHP attribútumok.
Miért Queuety?
Az állapot az MySQL-ban él
A várólista sorai, a munkafolyamat állapota, a naplók, a jelek és az adatfolyam adatdarabjai az MySQL-ban tárolódnak, így a munkafolyamat-kezelő újraindításakor nem vész el a vezérlés állapota. Minden lépéshatárnál egyetlen tranzakcióban véglegesül az állapotfrissítés, a feladat befejezése és a következő feladat sorba állítása.
A weboldal-kéréstől függetlenül
A WP-Cron csak oldalmegtekintéskor fut le, egy 60 másodperces LLM-hívást pedig megszakít a 30 másodperces PHP időtúllépés. A Queuety munkafolyamat-kezelői hosszan futó WP-CLI folyamatban futnak, és forgalomra várakozás nélkül veszik fel a munkát.
Védőkorlátok az ügynökfuttatásokhoz
A for_each() kvórumüzemmóddal, jóváhagyási kapukkal és olyan korlátokkal, mint a max_transitions() és a max_state_bytes(), meghatározott keretek között tartja a hosszan futó ügynökfuttatásokat.
Használható a(z) WordPress rendszeren kívül is
Az adatbázis-alapú mag bármely olyan PHP folyamatban fut, amely képes ugyanahhoz az adatbázishoz kapcsolódni. Így egy másik alkalmazás feladatokat indíthat, jeleket küldhet, és lekérdezheti a munkafolyamat állapotát. A műveletindítókhoz, a WP-Cron hídhoz és a WP-CLI parancsokhoz továbbra is szükség van a WordPress-ra.
Összehasonlítás
Hogyan viszonyul a(z) Queuety az ütemezőkhöz és munkafolyamat-motorokhoz, amelyeket a WordPress fejlesztői már ismernek.
| Eszköz | Amiben jó | Különbségek Queuety-hoz képest |
|---|---|---|
| WP-Cron | Amiben jóA(z) WordPress részeként működik, nem igényli a rendszerütemező elérését megosztott tárhelyen, és az esedékes időpontban el nem induló feladat a következő oldalbetöltéskor fut le, nem vész el. | Különbségek Queuety-hoz képestA Queuety munkafolyamat-kezelői a webhely forgalmától függetlenül futnak, és hosszú élettartamú wp queuety work folyamatot igényelnek. A WP-Cron hídja ütemezett feladatokká alakítja az ismétlődő eseményeket, de az azokhoz tartozó hook-visszahívásokat még nem futtatja, ezért azokért továbbra is a WP-Cron felel. |
| Action Scheduler | Amiben jóSzerverhozzáférés nélkül is használható bővítményekben és sablonokban való terjesztésre. Havonta több millió fizetést dolgoz fel az előfizetésekhez, valamint webhookokat a WooCommerce számára, és minden műveletet naplóz a kezelőfelületen. | Különbségek Queuety-hoz képestAz Action Scheduler egy későbbi időpontra ütemezi egy hook futtatását, például egy késleltetett do_action()-t. A Queuety többlépéses munkafolyamatokat kínál, amelyek állapota a lépések között is megmarad, továbbá jel- és jóváhagyásra várakozást, valamint állapotgépeket. Ezek a WP-CLI parancsaival, például a wp queuety workflow timeline paranccsal vizsgálhatók. |
| Temporal | Amiben jóTartós végrehajtási platform: az eseménytörténet rögzíti a munkafolyamat minden lépését, így a futás összeomlás vagy kiesés után az utolsó rögzített eseménytől folytatódik. A Temporal Cloud alternatívát kínál a szolgáltatás saját üzemeltetésére. | Különbségek Queuety-hoz képestA Temporal Service egy Go-kiszolgálóból és egy adatbázisból áll, amelyek az alkalmazás mellett futnak. A Queuety az állapotát a WordPress adatbázis-kapcsolat MySQL tábláiban tárolja, és a munkafolyamat-kezelőket a WP-CLI segítségével futtatja. |
Kérdések és válaszok
Rövid válaszok a Queuety dokumentációjából.
Az alapértelmezett várólistán lévő egyszerű feladatokhoz nem. A bővítmény percenként egy egyszeri munkafolyamat-kezelőt futtat a WordPress cron segítségével, amíg a WordPress cron fut, és futásonként egy feladatot kezel. Az ismétlődő ütemezésekhez, egyéni várólistákhoz és alacsonyabb késleltetéshez dedikált wp queuety work folyamat szükséges.
Nem. A mysqli vagy a pdo_mysql szükséges, és a rendszer alapértelmezés szerint a mysqli-t választja a WordPress alatt. Az QUEUETY_DB_DRIVER értékét auto, mysqli vagy pdo értékre állítva kényszeríthet ki egy illesztőprogramot.
A feladatok igénylése SELECT ... FOR UPDATE SKIP LOCKED használatával történik, amelyet a MySQL a 8.0-s verziótól, a MariaDB pedig a 10.6-os verziótól támogat. A projekt CI-folyamata MySQL 8.0-n fut.
Igen, az adatbázis-alapú mag közvetlen Connection kapcsolaton keresztül működteti a feladatokat, munkafolyamatokat, jeleket, állapotgépeket, műtermékeket, naplókat, mérőszámokat és ütemezéseket. A munkafolyamat-kezelői csoportokhoz a DB_HOST, DB_NAME, DB_USER és DB_PASSWORD konstansokra is szükség van. A Queuety::on_action(), a replace_wp_cron(), a bővítményindítás és a wp queuety parancsok továbbra is a WordPress rendszert igénylik.
Még nem. A Queuety::replace_wp_cron() a rendszeresen ismétlődő wp_schedule_event() eseményeket Queuety ütemezésekké alakítja, de a hozzájuk tartozó hook-visszahívásokat még nem futtatja. Azokat az eseményeket, amelyeknek mindenképpen le kell futniuk, továbbra is a WP-Cron rendszerre bízza. A wp_schedule_single_event() eseményeit továbbra is a WP-Cron kezeli.
A wp queuety work --workers=N rögzített számú folyamatból álló csoportot indít, és újraindítja az összeomló alfolyamatokat; ehhez a pcntl és posix bővítmények szükségesek. A --min-workers és --max-workers kapcsolók olyan alkalmazkodó munkafolyamat-kezelői csoportot indítanak, amely a várólista méretének növekedésekor bővül, majd a terhelés csökkenésekor szűkül.
Telepítse a bővítményt, indítson el egy munkafolyamat-kezelőt, és haladjon végig az útmutatókon az első feladattól a jóváhagyási munkafolyamatokig és az állapotgépekig.