Darbinieki

Darbinieki ir ilgstoši darbojošies procesi, kas aptaujā datubāzi, meklējot gaidošus uzdevumus, tos izpilda un virza darbplūsmas uz priekšu. Komanda wp queuety work darbojas WP-CLI vidē, bet pati rinda tiek paņemta tieši no MySQL, izmantojot labāko pieejamo Queuety DB draiveri.

Spraudnis instalē arī noklusēto reizi minūtē palaisto WordPress cron rezerves mehānismu vidēm bez piekļuves čaulai. Šajā lapā aplūkoti atsevišķi WP-CLI darbinieki, kas ir ieteicamais izvietošanas režīms lielākai caurlaidspējai.

Darbinieka palaišana

wp queuety work

Tas palaiž vienu darbinieku rindā default. Tas darbojas ciklā: paņem uzdevumu, izpilda to un atkārto. Kad rinda ir tukša, tas nogaida QUEUETY_WORKER_SLEEP sekundes (noklusējums: 1) un tad aptaujā rindu vēlreiz.

Opcijas

# 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

Vairāku rindu prioritātes

Viens darbinieks var apstrādāt vairākas rindas prioritāšu secībā. Padodiet rindu nosaukumu sarakstu, kas atdalīts ar komatiem, izmantojot --queue:

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

Darbinieks mēģina paņemt uzdevumu no katras rindas norādītajā secībā. Vispirms tas pārbauda critical. Ja critical ir uzdevums, tas to apstrādā. Ja critical ir tukša, tas pāriet pie default un pēc tam pie low. Tāpēc augstākas prioritātes rindas vienmēr tiek iztukšotas pirms zemākas prioritātes rindām.

Kā darbojas prioritāšu secība

Katrā ciklā darbinieks mēģina paņemt uzdevumu no saraksta pirmās rindas. Ja tā ir tukša vai apturēta, darbinieks pāriet pie nākamās rindas un turpina, līdz atrod uzdevumu vai pārbauda visu sarakstu. Ja nevienā rindā uzdevums nav atrasts, darbinieks nogaida un mēģina vēlreiz. Šis ir stingrs prioritāšu modelis, tāpēc pastāvīga critical uzdevumu plūsma atņems resursus rindām default un low. Ja zemākas prioritātes rindām jānodrošina garantēta caurlaidspēja, izmantojiet atsevišķus darbiniekus.

Vairāku rindu izmantošana PHP vidē

Metodes Worker::run() un Worker::flush() pieņem virkni vai masīvu:

// 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' );

Izvietošanas stratēģijas

Atsevišķi darbinieki katrai rindai sniedz pilnīgu kontroli pār vienlaicīgas izpildes apjomu un izolāciju. Katrai rindai ir savs darbinieka process(es), un citas rindas to nevar atstāt bez resursiem:

[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

Prioritāšu secība ar vienu darbinieku ir vienkāršāk pārvaldāma un labi darbojas, ja zemākas prioritātes rindas var pieļaut aizkavēšanos:

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

Varat arī apvienot abas pieejas: atsevišķus darbiniekus critical, lai nodrošinātu caurlaidspēju, un darbinieku ar prioritāšu secību visam pārējam:

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

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

Resursiem pielāgota pieņemšana

Darbinieki dara vairāk nekā tikai pārņem nākamo gaidošo rindu. Pirms pārņemtā darba sākšanas Queuety var veikt sākotnējās piekļuves pārbaudes, pamatojoties uz darba vienlaicīguma grupu un neseno šī apstrādātāja izpildes profilu.

Plašāku modeļa aprakstu, tostarp to, kā tas saistīts ar darbu metadatiem un darbplūsmu budžetiem, skatiet sadaļā Resursu pārvaldība.

Vienlaicīguma grupa nosaka kopīgu limitu vairākiem apstrādātājiem vai darbu klasēm. Ja vairākiem resursietilpīgiem pakalpojumu sniedzējiem piešķirat vienu un to pašu grupu un limitu, darbinieks atbrīvos tikko pārņemto darbu, nevis sāks to, kad grupas limits būs sasniegts. Tādējādi neatkarīgas rindas vienlaikus nepārslogo vienu pakārtoto sistēmu tikai tāpēc, ka ir vairāki dīkstāvē esoši darbinieki.

Nesenie izpildes žurnāli arī nodrošina vienkāršu piekļuves profilu. Ja ir iespējota resursu piekļuves kontrole, Queuety aplūko neseno vidējo ilgumu un šobrīd darbināmā apstrādātāja maksimālo atmiņas patēriņu. Ja pašreizējais darbinieks jau tuvojas konfigurētajam atmiņas limitam, rindas vai pakalpojumu sniedzēju grupas svērtais budžets jau ir izsmelts, pašreizējā konteinerā, šķiet, nepietiek atlikušās atmiņas šī apstrādātāja novērotajam profilam vai --once tipa izpilde tuvojas laika limitam, Queuety atliek darbu, nevis sāk izpildi, kas, visticamāk, netiks pabeigta bez problēmām.

Šo politiku ieslēdziet darba definīcijā, nevis darbinieka komandā:

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,
        ];
    }
}

Šos pašus metadatus var pievienot izpildāmu darbu klasēm ar publiskiem rekvizītiem vai atsevišķai izpildei, izmantojot PendingJob::concurrency_group() un PendingJob::cost_units().

Darbinieka puses piekļuves profilu kontrolē šīs konstantes:

Darbinieka dzīves cikls

Darbinieks pēc pašreizējā darba pabeigšanas pārtrauc darbību korekti, ja ir izpildīts kāds no šiem nosacījumiem:

Pēc apstāšanās darbinieks tiek korekti izslēgts. Produkcijas vidē procesu pārvaldnieks to automātiski palaiž no jauna.

Signāli vēl netiek apstrādāti korekti (#4). Atsevišķs wp queuety work process neiestata signālu apstrādātāju, tāpēc SIGTERM vai SIGINT (Ctrl+C) to nekavējoties pārtrauc, pat ja darbs vēl nav pabeigts. Šis darbs paliek processing, līdz novecojušo darbu atkopšana to atiestata pēc QUEUETY_STALE_TIMEOUT sekundēm, tāpēc apstrādātājiem jābūt drošiem atkārtotai palaišanai. Darbinieku kopa pārsūta SIGTERM saviem pakārtotajiem procesiem, taču tie uz to nereaģē, tāpēc kopa turpina darboties, līdz procesi apstājas kāda iepriekš minētā iemesla dēļ. Ja jāaptur kopa, iestatiet procesu pārvaldniekam apstāšanās noildzi, pēc kuras tas nosūta SIGKILL.

Vairāku darbinieku vienlaicīga izpilde

Karodziņš --workers=N palaiž N pakārtotos procesus, izmantojot pcntl_fork(). Katrs pakārtotais process izveido savu datubāzes savienojumu un apstrādā darbus neatkarīgi. Galvenais process uzrauga pakārtotos procesus un no jauna palaiž tos, kas avarē.

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

Prasības: Jābūt instalētiem pcntl un posix PHP paplašinājumiem (bez pcntl komanda neizdodas ar kļūdu "pcntl extension is required for --workers=N."), un katrs pakārtotais process izmanto savu datubāzes savienojumu, tāpēc iestatījumā MySQL max_connections jāparedz pietiekami daudz savienojumu visai darbinieku kopai. Adaptīvajām kopām (--min-workers/--max-workers) ir tādas pašas prasības.

Adaptīvas darbinieku kopas

Adaptīvās kopas uztur vismaz noteiktu skaitu aktīvu darbinieku un pēc tam palielinās vai samazinās konfigurētajās robežās:

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

Galvenais process uzrauga apstrādei pieejamo darbu uzkrājumu atlasītajās rindās un pielāgo pakārtoto procesu skaitu šim uzkrājumam, nepārsniedzot konfigurēto maksimumu. Kad rinda kļūst mierīga, kopa nogaida dīkstāves periodu, pirms samazina darbinieku skaitu, lai īslaicīgi darba pieplūdumi uzreiz neizraisītu procesu saraksta izmaiņas.

Mērogošana joprojām ir piesardzīga. Ja Queuety var nolasīt konteinera vai resursdatora atmiņas datus, tas nepievieno pakārtotus procesus, ja atlikusī atmiņa nav pietiekama vēl viena pilna darbinieka resursu limitam.

Galvenā procesa mērogošanas ciklu kontrolē:

Novecojušu darbu atkopšana

Ja darbinieks avarē, apstrādājot darbu, tā statuss paliek processing. Ilgstoši darbojošs darbinieks aptuveni reizi minūtē pārbauda, vai nav darbu, kas processing atradušies ilgāk par QUEUETY_STALE_TIMEOUT sekundēm. Novecojis darbs, kam vēl ir atlikuši mēģinājumi, tiek mēģināts vēlreiz pēc gaidīšanas perioda; darbs, kam visi mēģinājumi jau izmantoti, tiek paslēpts, un tā darbplūsma tiek atzīmēta kā neveiksmīga. --once darbinieki un WP-Cron rezerves mehānisms šo pārbaudi neveic.

Novecojušos darbus var atkopt manuāli:

wp queuety recover

Iztukšošanas režīms

Apstrādā visus gaidošos darbus un iziet. Noder testēšanai vai vienreizējai pakešapstrādei:

wp queuety flush
wp queuety flush --queue=emails

Izvietošana produkcijas vidē

Produkcijas vidē izmantojiet procesu pārvaldnieku, lai darbinieki turpinātu darboties. Tālāk aprakstīti divi izplatīti risinājumi.

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

Iespējojiet un palaidiet:

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

Izvietošanas ieteikumi

Ja nepieciešama stingrāka izolācija, katrai rindai palaidiet atsevišķus darbiniekus. Izmantojiet --workers=N, ja darba slodze galvenokārt noslogo procesoru, bet, ja tā galvenokārt izmanto ievadi/izvadi, priekšroku dodiet atsevišķi uzraudzītiem darbiniekiem. Iestatiet QUEUETY_WORKER_MAX_JOBS, ja vēlaties periodiski restartēt procesus, lai atbrīvotu atmiņu, un sekojiet līdzi buried skaitam, izmantojot tīmekļa āķus vai mērījumus.