Queue-ներ և background worker-ներ

01Ինչու queue-ներ. producer-ներ, consumer-ներ և broker-ներ

Պատկերացրեք ռեստորանի պատվերների ձողը։ Մատուցողը (producer) ամրացնում է պատվերի թերթիկը և վերադառնում հաճախորդների մոտ. խոհարարները (consumer) վերցնում են թերթիկները, երբ ազատ են։ Եթե տասը պատվեր միանգամից է գալիս, թերթիկները սպասում են ձողի վրա, իսկ մատուցողը չի «սառչում»։ Ծրագրային ապահովման մեջ այդ ձողը broker-ն է՝ Redis, տվյալների բազայի աղյուսակ, RabbitMQ կամ SQS։ Ձեր վեբ հավելվածը producer-ն է, worker պրոցեսները՝ consumer-ները։ Առավելությունները՝ արագ պատասխաններ, տրաֆիկի գագաթների հարթեցում, դանդաղ ծառայությունների ձախողումների մեկուսացում և worker-ների մասշտաբավորում վեբ սերվերներից անկախ։ Գինը՝ աշխատանքը դառնում է ասինխրոն, ուստի պետք է մտածել retry-ների, կրկնօրինակների, հերթականության և մոնիթորինգի մասին։

• Job. փոքր հաղորդագրություն՝ տեսակով և տվյալներով, իդեալում՝ միայն id-ներ, ոչ թե ամբողջական օբյեկտներ։
• Queue-ների անունները բաժանում են առաջնահերթությունները՝ critical, default, emails, reports։
• Concurrency. քանի job է worker-ը միաժամանակ կատարում։

02Retry-ներ, backoff և dead-letter queue-ներ

Job-երը ձախողվում են. վճարման API-ի timeout է լինում, տվյալների բազան deadlock է ընկնում, երրորդ կողմը վերադարձնում է 503։ Կրկնեք, բայց զգույշ։ Exponential backoff-ը յուրաքանչյուր անգամ ավելի երկար է սպասում (օրինակ՝ 10 վայրկյան, 1 րոպե, 5 րոպե)՝ մյուս կողմին վերականգնվելու ժամանակ տալով. jitter-ը ցրում է retry-ները, որպեսզի դրանք բոլորը միաժամանակ չհարվածեն։ Սահմանափակեք փորձերի քանակը։ Տարբերակեք սխալները. timeout-ը արժե կրկնել, իսկ validation սխալը («հաճախորդը գոյություն չունի») ընդմիշտ կձախողվի, ուստի այն անմիջապես նշեք որպես failed։ Վերջին փորձից հետո job-ը տեղափոխեք dead-letter queue (Laravel-ում՝ failed_jobs աղյուսակ, BullMQ-ում՝ failed set)։ Ինչ-որ մեկը պետք է նայի դրան. alert դրեք ձախողումների քանակի վրա և ստեղծեք միջոց՝ պատճառը շտկելուց հետո job-երը դիտելու և նորից գործարկելու համար։

1class SyncOrderToErp implements ShouldQueue
2{
3    use Queueable;
4 
5    public int $tries = 5;
6    public int $timeout = 60;
7 
8    public function __construct(public int $orderId) {}
9 
10    public function backoff(): array
11    {
12        return [10, 60, 300, 900];
13    }
14 
15    public function handle(ErpClient $erp): void
16    {
17        $order = Order::findOrFail($this->orderId);
18        $erp->upsertOrder($order); // idempotent by order id on the ERP side
19    }
20}

03Idempotent job-եր. անվտանգ է երկու անգամ գործարկել

Queue-ների մեծ մասը երաշխավորում է at-least-once առաքում. job-ը կարող է երկու անգամ գործարկվել, օրինակ, եթե worker-ը crash է լինում աշխատանքն անելուց հետո, բայց մինչև acknowledge անելը։ Ուստի յուրաքանչյուր job պետք է լինի idempotent, այսինքն՝ նորից գործարկելը լրացուցիչ ազդեցություն չունենա։ Տեխնիկաներ՝ օգտագործեք բնական unique key (ստեղծեք 123 պատվերի հաշիվ-ապրանքագիրը միայն եթե այն գոյություն չունի), պահեք «մշակված է» նշիչ unique constraint-ով, insert-ների փոխարեն օգտագործեք upsert-ներ և վճարային պրովայդերներին փոխանցեք idempotency key։ Գործելուց առաջ ստուգեք վիճակը («արդեն ուղարկվե՞լ է»)։ Exactly-once առաքումը համակարգերի միջև հիմնականում առասպել է. exactly-once ազդեցությունը գալիս է idempotent handler-ներից։ Խուսափեք նաև դասական race-ից. job-երը dispatch արեք միայն տվյալների բազայի transaction-ի commit-ից հետո, այլապես worker-ը կարող է վերցնել job մի տողի համար, որը դեռ գոյություն չունի։

04BullMQ-ն Node-ում

BullMQ-ն Node-ի համար Redis-ի վրա հիմնված ստանդարտ queue-ն է։ Queue-ն ավելացնում է job-եր, Worker-ը մշակում է դրանք սահմանված concurrency-ով, իսկ option-ները կառավարում են փորձերը, backoff-ը, ուշացումները, առաջնահերթությունը և մաքրումը։ Կրկնօրինակումից խուսափելու համար սահմանեք jobId. արդեն գոյություն ունեցող id-ով job ավելացնելն անտեսվում է։ Կրկնվող աշխատանքի համար օգտագործվում են job scheduler-ներ (upsertJobScheduler)՝ cron pattern-ով կամ interval-ով. BullMQ v6-ում հին repeat option-ը հանվել է scheduler-ների օգտին։ Worker-ները գործարկեք API-ից առանձին պրոցեսներով, որպեսզի ծանր job-երը երբեք չդանդաղեցնեն հարցումները, և յուրաքանչյուր queue-ին տվեք իր concurrency-ն։ Redis-ը պետք է կարգավորված լինի maxmemory-policy noeviction-ով, այլապես Redis-ը կարող է լուռ ջնջել job-երը։

1import { Queue, Worker } from 'bullmq';
2const connection = { host: '127.0.0.1', port: 6379 };
3 
4export const webhooks = new Queue('webhooks', { connection });
5 
6await webhooks.add('deliver', { eventId }, {
7  jobId: 'evt-' + eventId,              // dedupe
8  attempts: 8,
9  backoff: { type: 'exponential', delay: 5_000 },
10  removeOnComplete: 1000,
11  removeOnFail: 5000,
12});
13 
14new Worker('webhooks', async (job) => deliverWebhook(job.data.eventId), {
15  connection,
16  concurrency: 10,
17});

05Scheduling և worker-ների աշխատեցում production-ում

Պլանավորված աշխատանքը (գիշերային հաշվետվություններ, բաժանորդագրությունների ժամկետի ավարտ, ժամային sync-եր) աշխատում է timer-ով։ Դասական cron-ը հրամանը գործարկում է ֆիքսված ժամերին. Laravel-ի scheduler-ին պետք է մեկ cron գրառում, իսկ մնացածը սահմանվում է կոդում. BullMQ-ի scheduler-ները ժամանակացույցերը պահում են Redis-ում։ Պլանավորված job-երը դարձրեք անվտանգ համընկնման համար կամ բացահայտ կանխեք համընկնումը, և գործարկեք դրանք միայն մեկ սերվերի վրա։ Worker-ները երկարատև պրոցեսներ են, ուստի process manager-ը պետք է դրանք կենդանի պահի. supervisor կամ systemd՝ Laravel worker-ների համար, pm2 կամ systemd՝ Node-ի համար, կամ Docker-ում մեկ container յուրաքանչյուր worker տեսակի համար։ Worker-ները վերագործարկեք յուրաքանչյուր deploy-ի ժամանակ, որպեսզի նոր կոդը բեռնեն, և տվեք նրանց graceful shutdown, որպեսզի ընթացքի մեջ գտնվող job-ը կարողանա ավարտվել։

1; /etc/supervisor/conf.d/app-worker.conf
2[program:app-worker]
3command=php /var/www/app/artisan queue:work redis --queue=critical,default --sleep=3 --tries=3 --max-time=3600
4process_name=%(program_name)s_%(process_num)02d
5numprocs=2
6user=app
7autostart=true
8autorestart=true
9stopwaitsecs=3600
10stdout_logfile=/var/log/app-worker.log

06Մուտքային և ելքային webhook-ներ

Մուտքային webhook-ներ (վճարային պրովայդերներից, ERP-ներից, առաքման ծառայություններից)՝ ստուգեք ստորագրությունը, պահեք raw իրադարձությունը, արագ պատասխանեք 200 և մշակեք այն job-ում։ Պրովայդերները կրկնում են, ուստի կրկնօրինակները հեռացրեք ըստ նրանց event id-ի։ Գումարի հարցում երբեք միայն payload-ին մի վստահեք. վճարման կարգավիճակը նորից ստացեք պրովայդերի API-ից։ Ելքային webhook-ներ (ձեր գործընկերներին)՝ իրադարձությունը գրեք outbox աղյուսակում նույն transaction-ի ներսում, ինչ բիզնես փոփոխությունը, թողեք, որ worker-ը այն առաքի, body-ն ստորագրեք HMAC-SHA256-ով և timestamp-ով, որպեսզի ստացողները կարողանան ստուգել այն և մերժել replay-ները, կրկնեք backoff-ով մեկ օր կամ ավելի, և գործընկերոջը ցույց տվեք առաքման log-երը։ Այս outbox pattern-ը երաշխավորում է, որ երբեք չեք ծանուցի rollback արված բանի մասին և չեք կորցնի commit արված իրադարձությունը։

07Ինչպես է job-ը «ամրագրվում»՝ visibility timeout-ներ, lock-եր և stalled job-եր

Երբ worker-ը վերցնում է job-ը, broker-ը այն չի ջնջում։ Այն որոշ ժամանակով թաքցնում է job-ը և սպասում հաստատման։ Եթե հաստատումը ժամանակին չի գալիս, broker-ը ենթադրում է, որ worker-ը մահացել է, և job-ը հանձնում է ուրիշին։ SQS-ում սա visibility timeout-ն է։ Laravel-ում դա retry_after-ն է config/queue.php-ում. եթե job-ը դեռ աշխատում է այդքան վայրկյանից հետո, մեկ այլ worker այն նորից է սկսում, ուստի job-ի timeout-ը միշտ պետք է կարճ լինի retry_after-ից, այլապես երկար job-երը զուգահեռ երկու անգամ կաշխատեն։ BullMQ-ն օգտագործում է lock, որը worker-ը անընդհատ թարմացնում է մշակման ընթացքում. եթե lock-ի ժամկետն անցնում է, օրինակ՝ որովհետև CPU-ծանր կոդը արգելափակել է event loop-ը, job-ը նշվում է որպես stalled և վերադարձվում waiting, իսկ չափից շատ stall-երից հետո ձախողվում է։ Երեք դիզայններն էլ տալիս են at-least-once առաքում, և հենց դա է պատճառը, որ idempotency-ն պարտադիր է։

1// config/queue.php
2'redis' => [
3    'driver' => 'redis',
4    'connection' => 'default',
5    'queue' => env('REDIS_QUEUE', 'default'),
6    'retry_after' => 960,     // longer than the slowest job's timeout
7    'block_for' => 5,
8    'after_commit' => true,   // push only after the DB transaction commits
9],
10 
11// Slow export job: public $timeout = 900; run it on a worker
12// started with --timeout=900, on its own queue.

08Զուգահեռության կառավարում՝ եզակիություն, համընկնում և rate limit-ներ

Retry-ներն ու զուգահեռ worker-ները նոր խնդիրներ են ստեղծում. նույն հաճախորդի երկու sync, որոնք մրցում են իրար հետ, կամ job-երի պոռթկում, որը բախվում է գործընկերոջ rate limit-ին։ Laravel-ը ձեզ տալիս է կառուցողական բլոկներ։ ShouldBeUnique-ը անտեսում է նոր dispatch-ը, քանի դեռ նույնական job-ը, ըստ uniqueId-ի, սպասման մեջ է։ WithoutOverlapping job middleware-ը թույլ է տալիս մեկ key-ի համար միաժամանակ աշխատել միայն մեկ job-ի, իսկ մյուսներին վերադարձնում է queue։ RateLimited-ը job-երի վրա կիրառում է անվանված rate limiter, իսկ ThrottlesExceptions-ը կրկնվող ձախողումներից հետո դանդաղեցնում է՝ գործելով որպես circuit breaker անկայուն API-ի համար. զուգակցեք այն retryUntil-ի հետ, որպեսզի retry-ները սահմանափակի ժամանակը, ոչ թե փորձերի քանակը։ Unique և overlap lock-երին պետք է cache store ատոմար lock-երով, օրինակ՝ Redis-ը կամ բազան։ BullMQ-ում deduplication տարբերակը անտեսում է նույն id-ով կրկնվող job-երը, իսկ worker limiter-ը սահմանափակում է job-երը ժամանակային պատուհանում։

1class SyncCustomerToCrm implements ShouldQueue, ShouldBeUnique
2{
3    use Queueable;
4 
5    public function __construct(public int $customerId) {}
6    public function uniqueId(): string
7    {
8        return (string) $this->customerId;
9    }
10 
11    public function middleware(): array
12    {
13        return [
14            new WithoutOverlapping('crm-'.$this->customerId),
15            new ThrottlesExceptions(10, 5 * 60), // 10 errors, then pause 5 min
16        ];
17    }
18 
19    public function retryUntil(): DateTime { return now()->addHours(6); }
20}

09Workflow-ներ՝ chain-եր, batch-եր և parent-child flow-եր

Իրական աշխատանքը հաճախ կախվածություններով մի քանի job է։ Chain-ը job-երը գործարկում է մեկը մյուսի հետևից և կանգ է առնում, եթե մեկը ձախողվում է. գեներացնել հաշիվ-ապրանքագիրը, ապա ուղարկել այն, ապա տեղեկացնել հաշվապահին։ Batch-ը շատ job-եր գործարկում է զուգահեռ և callback է կանչում, երբ բոլորն ավարտվում են, ինչը հարմար է հազարավոր փոքր job-երի բաժանված import-ների և export-ների համար. Laravel-ը առաջընթացին հետևում է job_batches աղյուսակում, իսկ դրա job-երն օգտագործում են Batchable trait-ը։ BullMQ-ում FlowProducer-ը ստեղծում է parent-child ծառեր, որտեղ parent-ը աշխատում է միայն բոլոր child-երի ավարտից հետո և կարող է կարդալ դրանց արդյունքները։ Յուրաքանչյուր քայլ նախագծեք idempotent և փոքր, որպեսզի մեկ քայլի retry-ը չկրկնի ամբողջ workflow-ը։ Երբ ավելի ուշ քայլը ձախողվում է այն բանից հետո, երբ նախորդները փոխել են արտաքին համակարգեր, ձեզ պետք է բացահայտ փոխհատուցում, օրինակ՝ ամրագրման չեղարկում, որովհետև queue-ն չի կարող հետ գլորել վճարումը։

1$batch = Bus::batch(
2    $orderIds->map(fn (int $id) => new ExportOrderRow($exportId, $id))->all()
3)
4    ->name('orders-export-'.$exportId)
5    ->allowFailures()
6    ->then(fn (Batch $batch) => BuildExportFile::dispatch($exportId))
7    ->catch(fn (Batch $batch, Throwable $e) => report($e))
8    ->finally(fn (Batch $batch) => CleanupExportChunks::dispatch($exportId))
9    ->onQueue('reports')
10    ->dispatch();
11 
12// Progress for the UI: Bus::findBatch($batch->id)->progress()

10Թողունակություն և observability՝ խորություն, տարիք և Little-ի օրենք

Քանի՞ worker է ձեզ պետք։ Little-ի օրենքը տալիս է առաջին պատասխանը. ընթացքի մեջ գտնվող job-երի միջին քանակը հավասար է ժամանման արագությանը՝ բազմապատկած մշակման միջին ժամանակով։ Եթե վայրկյանում 30 job է գալիս, և յուրաքանչյուրը տևում է 200 մվ, ձեզ պետք է առնվազն 6 զուգահեռ slot՝ պարզապես հետ չմնալու համար, և ավելին՝ պիկերի ու retry-ների համար։ Միայն queue-ի խորությունը մոլորեցնող է. 10,000 փոքրիկ job կարող է մաքրվել վայրկյանների ընթացքում, մինչդեռ 50 դանդաղը կարող է ժամերով հետ մնալ։ Ամենաօգտակար մեկ մետրիկան յուրաքանչյուր queue-ի ամենահին սպասող job-ի տարիքն է՝ ահազանգով թիրախի նկատմամբ, օրինակ՝ «email-ները 60 վայրկյանի ընթացքում»։ Հետևեք նաև թողունակությանը, ձախողումների մակարդակին և մշակման ժամանակի պերցենտիլներին։ Horizon-ը կարող է ավտոմատ հավասարակշռել worker-ները queue-երի միջև, իսկ php artisan queue:monitor-ը կարող է event արձակել, երբ queue-ն աճում է շեմից ավելի։ Multi-tenant համակարգերում հետևեք արդարությանը. մեկ tenant-ի import-ը չպետք է ուշացնի բոլորի կտրոնները։

• Worker-ները autoscale արեք ըստ ամենահին job-ի տարիքի, ոչ թե CPU-ի։
• Առանձին queue-եր ըստ ուշացման թիրախի՝ critical, default, bulk։
• Սահմանափակեք զուգահեռությունը ըստ tenant-ի ծանր job տեսակների համար։