Перейти до основного вмісту
Версія: 2.0

Зіставлення й диспетчеризація завдань

Використовуйте цей посібник, щоб зрозуміти, як Durable Workflow знаходить готову роботу, призначає сумісним worker і масштабує цей шлях поза опитуванням усього кожним вузлом. Це контракт опитування завдань workflow та activity, пробудження черг і окремого розгортання ролі matching.

Durable Workflow розділяє дві відповідальності:

  • стійка історія й стан завдань залишаються в базі даних;
  • matching визначає живого worker для наступного допустимого завдання.

Це важливо ще до введення окремої служби matching. Оператори можуть розглядати виявлення готових завдань, володіння чергами, зміну оренд і зворотний тиск як одну явну роль, а не випадкові наслідки кожного процесу worker.

Що виконує роль matching​

Роль matching відповідає за:

  • виявлення готових завдань workflow та activity;
  • звуження допустимого набору за простором імен, підключенням, чергою та сімейством сумісності;
  • надання завдання одному worker за раз;
  • перетворення успішного claim на оренду з часом спливання;
  • збереження того самого завдання після невдалого claim, спливання оренди або зникнення worker;
  • видимість стану пробуджень і backlog для оператора.

Matching визначає можливість наступного виконання. Стійка історія, replay workflow і виконання завдань залишаються окремими відповідальностями.

Форми розгортання​

Durable Workflow зараз підтримує три практичні форми:

Matching усередині worker​

Це типова форма. Процеси worker використовують long-poll готової роботи та відсікання під час claim, щоб орендою завдання володів лише один worker за раз.

Використовуйте її, якщо:

  • працюєте на одному вузлі або невеликому наборі;
  • тиск черг помірний;
  • окремий daemon matching ще не потрібен.

Matching HTTP усередині Server​

У розгортанні окремого Server зовнішні worker звертаються до того самого контракту matching через протокол worker:

  • POST /api/worker/workflow-tasks/poll
  • POST /api/worker/activity-tasks/poll

Server стає мережевою точкою входу того самого процесу виявлення готових завдань, claim, heartbeat і завершення.

Окреме розгортання ролі matching​

Більші набори можуть зосередити загальне виявлення готових завдань в окремому процесі matching. Поточна задокументована форма оператора:

php artisan workflow:v2:repair-pass --loop

Запустіть цей daemon окремим процесом і задайте DW_V2_MATCHING_ROLE_QUEUE_WAKE=0 на вузлах лише виконання, щоб вони припинили загальне пробудження worker черг на кожному tick циклу.

Використовуйте форму, якщо:

  • вузли виконання мають зосередитися на replay та activity;
  • незалежне загальне опитування створює зайву конкуренцію ресурсів;
  • потрібне явне місце відповідальності за виявлення готових завдань і частоту проходів.

Окрема роль змінює місце matching. Контракт протоколу worker, семантика poll, claim, оренд і повторної доставки залишаються тими самими.

Виявлення готових завдань​

Matching шукає стійкі завдання, які справді готові виконуватися зараз:

  • вид завдання відповідає poller: workflow або activity;
  • завдання має стан ready;
  • настав його available_at;
  • фільтри простору імен, черги, підключення й сумісності ще відповідають;
  • poll activity також потребує відповідного оголошеного типу activity.

Пробудження long-poll прискорюють виявлення. Якщо сигнал затриманий або відсутній, завдання все одно видиме через стійке опитування. Збій пробудження може підвищити затримку, але не залишити роботу без шляху виконання.

Claim, оренда й зворотний тиск​

Matching лише пропонує можливість. Володіння починається після успішного claim одного worker й отримання оренди.

Оренда визначає зворотний тиск Durable Workflow:

  • один worker володіє завданням до поновлення, завершення, звільнення чи спливання оренди;
  • невдалий або застарілий worker не утримує завдання назавжди;
  • повторна доставка звичайна й має оброблятися як частина виконання щонайменше один раз;
  • несумісні worker отримують явну відмову й не забирають оренду.

Завдяки орендам тиск черг проявляється як backlog, застарілі оренди чи повторна доставка, а не прихована втрата в пам’яті.

Розділення черг​

Основні примітиви розділення:

  • простір імен для меж орендаря чи середовища;
  • підключення та черга для меж маршрутизації роботи;
  • сімейство сумісності для безпечної маршрутизації маркерами;
  • фільтри типів activity для worker лише вибраних activity.

Використовуйте окремі черги для сильнішої ізоляції, незалежних пулів worker або інших бюджетів залежностей. Сімейства сумісності потрібні, коли та сама черга має працювати під час оновлення чи відкату без переходу незавершеної роботи до несумісних виконавців.

Сигнали пробудження й окремі проходи​

Сигнали пробудження скорочують час між готовністю завдання й виявленням poller. Стійке джерело істини залишається в базі даних.

У типовій формі worker черг можуть надсилати пробудження зі звичайного циклу. За окремої ролі matching вузли лише виконання вимикають загальний шлях пробудження, а daemon matching визначає частоту проходів.

Засоби налаштування:

  • DW_V2_MATCHING_ROLE_QUEUE_WAKE визначає пробудження в worker на вузлах виконання;
  • DW_WAKE_SIGNAL_TTL_SECONDS визначає час видимості маркерів пробудження;
  • тайм-аути long-poll визначають тривалість очікування роботи poller.

Що мають спостерігати оператори​

Використовуйте ці інтерфейси разом:

  • GET /api/cluster/info для топології ролей вузла: current_shape, current_process_class, поточні ролі й повний контракт matching_role: queue_wake_enabled, форма розгортання shape, wake_owner, task_dispatch_mode, фіксовані partition_primitives і поточний backpressure_model;
  • видимість черг завдань для глибини готової роботи, активних слотів і throttling;
  • видимість набору worker для активних і застарілих poller кожної черги;
  • dw system:operator-metrics --json або /api/system/operator-metrics для того самого локального контракту matching_role поруч із живими лічильниками backlog, відновлення, worker і здоров’я процесу відповіді;
  • здоров’я та діагностику Waterline для нездорових завдань, застарілих оренд і прогалин сумісних worker;
  • перевірки поступового оновлення під час вікна співіснування, коли matching має блокувати небезпечні claims.

Якщо вік найстарішого готового завдання зростає за доступних сумісних worker, шлях matching не просуває роботу достатньо швидко. Якщо готові завдання зберігаються, але сумісний worker не може їх забрати, потрібна діагностика сумісності.

Коли вводити окрему роль matching​

Переходьте від типового matching усередині worker до окремої ролі, якщо:

  • загальне опитування створює видиму конкуренцію бази даних чи кешу;
  • вузли виконання мають перестати витрачати ресурси на проходи готових завдань;
  • справедливість черг і відповідальність диспетчеризації потрібно розглядати як одну явну підсистему;
  • потрібен окремий процес для масштабування, нагляду й діагностики виявлення готових завдань.

Залишайте типову форму для малого набору, коли основна потреба — зрозуміла поведінка оновлення й сумісності без нової топології.