← Усі статті

Черга фонових задач на PostgreSQL і Go: проєкт Swig

Таблиця jobs, блокування рядків, JSONB, LISTEN/NOTIFY і воркери — без Redis, якщо Postgres уже в стеку.

Теги
BackendБази данихНовини
Черга фонових задач на PostgreSQL і Go: проєкт Swig
Зміст

Коротко

Не кожна повільна операція має блокувати HTTP-відповідь: листи, webhooks, ресайз зображень, звіти — класичні фонові задачі. На Dev.to розібрали Swig — чергу на Go зі зберіганням jobs у PostgreSQL, без окремого брокера повідомлень.

Що сталося

Автор відштовхується від простої думки: якщо Postgres уже крутиться в проді, навіщо піднімати Redis «лише заради черги»? Swig показує, як укласти фонову роботу в ту саму СУБД, спираючись на транзакції та блокування рядків.

Є таблиця jobs з payload у JSONB, статусами, лічильником спроб і мітками часу. Воркери на Go забирають задачу всередині транзакції — два процеси не повинні взяти один і той самий рядок. Поруч реєстр воркерів і провідний процес для обслуговування: прострочені lease, повторні спроби, прибирання старих записів.

Інтерфейси в Go описують поведінку обробника; goroutines дають паралелізм; context — скасування та таймаути. Щоб не крутити нескінченне опитування БД, використовують LISTEN/NOTIFY: після вставки job воркери отримують сигнал.

Чому це важливо

Багато команд за замовчуванням додають RabbitMQ або Redis, хоча навантаження — десятки–сотні задач на секунду, а критичніше передбачуваність і один контур експлуатації. Черга на Postgres ділить бекапи, моніторинг і міграції з основним застосунком.

Чесне обмеження: при дуже високому QPS і жорсткому SLA на затримку доставки спеціалізований брокер може виграти. Для типового вебпродукту схема «таблиця + воркери» живе роками.

На практиці

  1. Спроєктуйте схему job: id, kind, payload jsonb, status, attempts, run_at, locked_at, locked_by.
  2. Забирайте задачу в транзакції з FOR UPDATE SKIP LOCKED.
  3. Робіть обробники ідемпотентними — повтор після збою не має двічі надіслати лист або списати гроші.
  4. Шліть NOTIFY після COMMIT вставки; раз на N секунд лишіть резервне опитування.
  5. Виділіть провідний процес для requeue завислих jobs і архівації історії.
  6. Метрики: глибина черги, вік найстарішої pending-задачі, частка failed.

Підсумок

Swig на Dev.to — навчальний каркас черги на PostgreSQL у Go. Якщо Postgres уже в стеку, має сенс оцінити такий контур до покупки другого сховища. Код і деталі схеми — в оригіналі.