graphile-worker, очередь задач на Postgres. Автор и основной разработчик — Бенджи Гиллам (Benjie Gillam), тот же человек, что делает PostGraphile.

Очередь задач в базе устроена просто ровно до второго воркера. Дальше встаёт вопрос, который решают все и по-разному: как двум процессам взять из одной таблицы разные задачи и не подраться за одну.

Postgres даёт готовый ответ — FOR UPDATE SKIP LOCKED: «возьми строки, пропуская те, что уже кем-то заняты». Но есть ещё именованные очереди — когда задачи с одинаковым именем обязаны выполняться строго по одной. И вот тут одного SKIP LOCKED уже мало.

Приезжает коммит с названием, которое ничего не обещает:

Add a few strategies

Сто строк в файле выбора задачи — src/sql/getJob.ts, строки 28–52 в том самом коммите. Описания у коммита нет — вся документация внутри, комментарием над настройкой. И это лучший вид документации, потому что она не про то, как работает код, а про то, что показали замеры:

0 — we're not using named queues; skip them! …it's the absolute fastest strategy.

1 — for each matched job, go lock its job queue if you can. …what Worker traditionally used… but these days its a terrible strategy unless you're still randomly generating queue names (don't do that!). Performance is abysmal if you have a large jobs table with many higher priority but stuck jobs.

2 — lock the job queues up front, then find a job to do. …seems to be the fastest strategy for jobs that aren't in a queue…

3 — explicitly avoid locked job queues, but risk multiple jobs in same queue running at same time. Strategy 3 is probably unsafe. Don't use it.

Четыре варианта, из них один — «скорее всего небезопасен, не пользуйтесь» (строка 48). Оставлен в коде и снабжён предупреждением, потому что кому-то он всё-таки может понадобиться.

Чуть ниже в том же файле лежит закомментированный кусок SQL с эпитафией — строки 98–101:

This strategy causes incredibly bad performance, presumably due to the lack of lock/skip locked

Эта стратегия даёт чудовищную производительность, предположительно из-за отсутствия lock/skip locked.

Его не удалили. Его положили рядом с надписью «пробовали, плохо» — чтобы следующий, кому эта идея покажется хорошей, сначала прочитал.

Слово presumably здесь важнее остального: автор не выдумывает объяснение задним числом, а честно помечает, что замер есть, а причина — догадка.

Через год и четыре месяца приходит коммит e56613e9 с названием, которое просится в рамку:

Go back to the old way of doing it

Минус 267 строк, плюс 73. Файл выбора задачи худеет на 177 строк. Настраиваемость выбрасывают целиком.

Четыре стратегии прожили полтора года и свернулись обратно в одну. Замеры при этом никуда не делись — описания остались в коде. Перестал существовать сам выбор.

Почему именно так, в коммите не объяснено: он идёт в серии из семи коммитов одного дня с названиями вроде Checkout basics и More backporting — то есть в середине крупной перекладки, а не отдельным решением. Так что от домыслов воздержимся: известно, что выбор из четырёх стратегий не пережил полутора лет.

Ссылки выше ведут в коммит ad21f2a1, а не на ветку, и это здесь не формальность: на main этого файла больше нет — его и снёс тот самый откат. Ссылка на ветку показала бы «страница не найдена» ровно там, где читатель пошёл смотреть, о чём речь.

У этой конструкции есть цена, и найти её можно не в коде, а в документации для пользователей — в разделе про обработку ошибок:

If the worker is terminated in a way that cannot be handled (e.g. process.exit(), segfault, SIGKILL, someone pulled the power cord, etc) then the jobs that that worker was executing remain locked for at least 4 hours. Every 8-10 minutes a worker will sweep for jobs that have been locked for more than 4 hours and will make them available to be processed again automatically.

Если воркер завершился так, что обработать это нельзя — …кто-то выдернул шнур… — то задачи, которые он выполнял, остаются заблокированными не менее четырẻх часов.

Вот она, вся арифметика в одном абзаце. Задача помечается взятой (locked_at) на время работы. Воркер умер — пометка осталась. Значит нужен ещё один механизм, который ходит и разблокирует; в проекте под него отдельный файл, resetLockedAt.ts.

Выдернули шнур — пользователь ждёт четыре часа. Не потому что кто-то недодумал, а потому что это честная цена за «пометить взятой».