Workerek

A workerek hosszú ideig futó folyamatok, amelyek függő feladatokért kérdezik le az adatbázist, végrehajtják őket, és továbbviszik a munkafolyamatokat. A wp queuety work parancs a WP-CLI környezetében fut, miközben a sorból közvetlenül a MySQL segítségével, a legjobb elérhető Queuety DB-illesztőprogramon keresztül veszi fel a feladatokat.

A bővítmény egy alapértelmezett, percenként egyszer futó WordPress cron tartalékmegoldást is telepít olyan környezetekhez, ahol nincs shell-hozzáférés. Ez az oldal a különálló WP-CLI workereket ismerteti, amelyek az ajánlott, nagyobb áteresztőképességű telepítési módot jelentik.

Worker indítása

wp queuety work

Ez egyetlen workert indít a default soron. Ciklusban fut: felvesz egy feladatot, végrehajtja, majd ismétli a folyamatot. Ha a sor üres, QUEUETY_WORKER_SLEEP másodpercig vár (alapértelmezés: 1), mielőtt újra lekérdezi.

Beállítások

# Process a specific queue
wp queuety work --queue=emails

# Process at most one job and exit
wp queuety work --once

# Run 4 concurrent workers
wp queuety work --workers=4

# Scale between 2 and 6 workers as backlog changes
wp queuety work --queue=providers --min-workers=2 --max-workers=6

Több sor prioritásai

Egyetlen worker több sort is feldolgozhat prioritási sorrendben. Adj át egy vesszővel elválasztott sornevekből álló listát a --queue számára:

wp queuety work --queue=critical,default,low

A worker a felsorolt sorrendben próbál feladatot felvenni az egyes sorokból. Először a critical sort ellenőrzi. Ha a critical tartalmaz feladatot, feldolgozza. Ha a critical üres, továbblép a default sorra, majd a low sorra. Ez azt jelenti, hogy a magasabb prioritású sorok mindig kiürülnek az alacsonyabb prioritásúak előtt.

Hogyan működik a prioritási sorrend

Minden ciklusban a worker megpróbál feladatot felvenni a lista első sorából. Ha az a sor üres vagy szüneteltetve van, továbblép a következőre, és így halad tovább, amíg fel nem talál egy feladatot, vagy el nem fogy a lista. Ha sehol sem talál feladatot, vár, majd újra próbálkozik. Ez szigorú prioritási modell: a critical feladatok folyamatos áradata kiéhezteti a default és low sorokat. Ha az alacsonyabb prioritású soroknak garantált áteresztőképességre van szükségük, használj külön workereket.

Több sor használata a PHP környezetében

A Worker::run() és a Worker::flush() metódus karakterláncot vagy tömböt is elfogad:

// Comma-separated string
Queuety::worker()->run( 'critical,default,low' );

// Array
Queuety::worker()->run( [ 'critical', 'default', 'low' ] );

// flush() also supports multi-queue
$count = Queuety::worker()->flush( 'critical,default,low' );

Telepítési stratégiák

A külön worker minden sorhoz teljes irányítást biztosít a párhuzamosság és az elkülönítés felett. Minden sornak saját workerje van process(es), így a többi sor nem éheztetheti ki:

[program:queuety-critical]
command=wp queuety work --queue=critical
numprocs=4

[program:queuety-default]
command=wp queuety work --queue=default
numprocs=2

[program:queuety-low]
command=wp queuety work --queue=low
numprocs=1

Az egyetlen workerrel megvalósított prioritási sorrend egyszerűbben kezelhető, és jól működik, ha az alacsonyabb prioritású sorok elviselik a késleltetést:

[program:queuety-worker]
command=wp queuety work --queue=critical,default,low
numprocs=2

A két megközelítést kombinálhatod is: használj külön workereket a critical számára az áteresztőképesség garantálásához, a többi feladathoz pedig prioritási sorrendű workert:

[program:queuety-critical]
command=wp queuety work --queue=critical
numprocs=2

[program:queuety-fallback]
command=wp queuety work --queue=default,low
numprocs=2

Erőforrás-tudatos felvétel

A workerek többet tesznek annál, mint hogy felveszik a következő függő sort. Mielőtt egy felvett feladat elindulna, a Queuety durva felvételi ellenőrzéseket végezhet a feladat párhuzamossági csoportja és az adott kezelő közelmúltbeli végrehajtási profilja alapján.

A tágabb modellről – többek között arról, hogyan kapcsolódik a feladatok metaadataihoz és a munkafolyamatok kereteihez – lásd az Erőforrás-kezelés oldalt.

A párhuzamossági csoport több kezelő vagy feladatosztály számára határoz meg közös felső korlátot. Ha több nagy erőforrásigényű szolgáltatónak ugyanazt a csoportot és korlátot állítod be, a worker felszabadítja az újonnan felvett feladatot, ahelyett hogy elindítaná, ha a csoport elérte a korlátját. Így a különálló sorok nem rohanják meg egyszerre ugyanazt a háttérrendszert csupán azért, mert több worker is tétlen.

A közelmúlt végrehajtási naplói egy egyszerű felvételi profilhoz is adatot szolgáltatnak. Ha az erőforrás-alapú felvétel engedélyezve van, a Queuety megvizsgálja a futtatandó kezelő közelmúltbeli átlagos időtartamát és csúcsmemória-használatát. Ha a worker már közel van a beállított memóriakorláthoz, egy sor vagy szolgáltatói csoport elérte súlyozott keretét, a jelenlegi konténerben a kezelő megfigyelt profilja alapján nem maradt elég memória, vagy egy --once jellegű futtatás közel van az időkerete végéhez, a Queuety elhalasztja a feladatot ahelyett, hogy olyan munkát indítana, amely valószínűleg nem fejeződik be hibamentesen.

A szabályzatot a munka definíciójánál kell bekapcsolni, nem a worker parancsánál:

class CallProviderStep implements \Queuety\Step {
    public function handle( array $state ): array {
        // ...
    }

    public function config(): array {
        return [
            'concurrency_group' => 'providers',
            'concurrency_limit' => 3,
            'cost_units' => 5,
        ];
    }
}

Ugyanezek a metaadatok nyilvános tulajdonságokkal rendelkező, kiosztható feladatosztályokhoz vagy egyetlen kiosztáshoz is hozzárendelhetők a PendingJob::concurrency_group() és a PendingJob::cost_units() segítségével.

A workeroldali felvételi profilt a következő konstansok szabályozzák:

A worker életciklusa

A worker az aktuális feladat befejezése után szabályosan leáll, ha az alábbi feltételek bármelyike teljesül:

Leállás után a worker szabályosan kilép. Éles környezetben egy folyamatkezelő automatikusan újraindítja.

A jelek kezelése egyelőre nem szabályos (#4). Egyetlen wp queuety work folyamat nem telepít jelkezelőt, ezért a SIGTERM vagy a SIGINT (Ctrl+C) azonnal leállítja, akár egy feladat közepén is. A feladat processing állapotban marad, amíg az elavultfeladat-helyreállítás QUEUETY_STALE_TIMEOUT másodperc után vissza nem állítja, ezért a kezelőknek biztonságosan újrapróbálhatóknak kell lenniük. A worker-készlet továbbítja a SIGTERM jelet a gyermekfolyamatainak, de azok nem reagálnak rá, így a készlet addig fut, amíg a fenti okok valamelyike miatt le nem állnak. Ha le kell állítanod egy készletet, állíts be időtúllépést a folyamatkezelőben, amely után az elküldi a SIGKILL jelet.

Több worker párhuzamos futtatása

A --workers=N jelző N gyermekfolyamatot indít a pcntl_fork() segítségével. Minden gyermekfolyamat saját adatbázis-kapcsolatot hoz létre, és önállóan dolgozza fel a feladatokat. A szülőfolyamat figyeli a gyermekfolyamatokat, és újraindítja az összeomlókat.

wp queuety work --queue=default --workers=4

Követelmények: Telepíteni kell a pcntl és a posix PHP bővítményeket (pcntl nélkül a parancs hibát jelez: „pcntl extension is required for --workers=N.”), és minden gyermekfolyamat saját adatbázis-kapcsolatot használ, ezért a MySQL max_connections beállításnak elegendőnek kell lennie a készlet számára. Az adaptív készletekre (--min-workers/--max-workers) ugyanezek a követelmények vonatkoznak.

Adaptív workerkészletek

Az adaptív készletek minimális számú workert tartanak készenlétben, majd a beállított tartományon belül növelik vagy csökkentik a számukat:

wp queuety work --queue=providers --min-workers=2 --max-workers=6

A szülőfolyamat figyeli a felvehető feladatok sorát a kiválasztott sorokban, és a gyermekfolyamatok számát ehhez igazítja, a beállított maximummal korlátozva. Amikor a sor forgalma lecsökken, a készlet kivárja a tétlenségi türelmi idő végét, mielőtt visszaskálázna, így a rövid kiugrások nem változtatják meg azonnal a folyamatlistát.

A felskálázás továbbra is óvatos. Ha a Queuety le tudja kérni a konténer vagy a gazdagép memóriaadatait, nem ad hozzá újabb gyermekfolyamatot, ha nincs elegendő szabad memória egy teljes worker futtatásához.

A szülőfolyamat skálázási ciklusát a következő beállítások szabályozzák:

Elakadt feladatok helyreállítása

Ha egy worker feladatfeldolgozás közben összeomlik, a feladat processing állapotban marad. Egy hosszan futó worker körülbelül percenként ellenőrzi, hogy vannak-e olyan feladatok, amelyek több mint QUEUETY_STALE_TIMEOUT másodperce vannak processing állapotban. A hátralévő próbálkozással rendelkező elakadt feladat az újrapróbálkozási késleltetés után újraindul; amelyik minden próbálkozását felhasználta, a sikertelenek közé kerül, a munkafolyamatát pedig sikertelennek jelöli. A --once workerek és a WP-Cron tartalékmegoldás nem végzik el ezt az ellenőrzést.

Az elakadt feladatok kézi helyreállítása:

wp queuety recover

Kiürítési mód

Az összes függő feladat feldolgozása, majd kilépés. Teszteléshez vagy egyszeri kötegelt feldolgozáshoz hasznos:

wp queuety flush
wp queuety flush --queue=emails

Telepítés éles környezetbe

Éles környezetben folyamatkezelővel gondoskodj a workerek folyamatos futtatásáról. Íme két gyakori megközelítés.

Supervisord

[program:queuety-default]
command=wp queuety work --queue=default
directory=/var/www/html
autostart=true
autorestart=true
numprocs=2
process_name=%(program_name)s_%(process_num)02d
stdout_logfile=/var/log/queuety-default.log
stderr_logfile=/var/log/queuety-default-error.log

[program:queuety-emails]
command=wp queuety work --queue=emails
directory=/var/www/html
autostart=true
autorestart=true
numprocs=1
stdout_logfile=/var/log/queuety-emails.log
stderr_logfile=/var/log/queuety-emails-error.log

Systemd

[Unit]
Description=Queuety Worker (default queue)
After=mysql.service

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/html
ExecStart=/usr/local/bin/wp queuety work --queue=default
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Engedélyezés és indítás:

sudo systemctl enable queuety-worker
sudo systemctl start queuety-worker

Telepítési tippek

Erősebb elkülönítéshez futtass külön workereket az egyes sorokhoz. CPU-intenzív munkaterhelésnél használd a --workers=N beállítást, főként I/O-intenzív terhelésnél pedig részesítsd előnyben az egyenként felügyelt workereket. Állítsd be a QUEUETY_WORKER_MAX_JOBS értékét, ha időszakos újraindításokkal szabadítanál fel memóriát, és kövesd nyomon a buried számát a webhookokon vagy a mérőszámokon keresztül.