Очередь задач в postgresql: масштабирование, паттерн inbox и сравнение с kafka и rabbitmq

Очередь задач на PostgreSQL: масштабирование, паттерн inbox и сравнение с Kafka и RabbitMQ

PostgreSQL можно использовать не только для хранения бизнес-данных, но и для обработки фоновых задач. Такой вариант часто выбирают, когда приложению нужна простая очередь, а отдельную инфраструктуру для брокера сообщений пока нецелесообразно разворачивать. Задачи размещаются в таблице, а обработчики забирают их и выполняют. Однако возможности базы данных не безграничны: при росте нагрузки важно правильно организовать конкурентную обработку и понимать, когда пора переходить на специализированное решение.

Минимальная таблица очереди обычно содержит идентификатор задачи, тип события или имя задания, полезную нагрузку, время создания, статус и число попыток обработки. В зависимости от требований добавляют срок аренды задачи, время следующего запуска, приоритет и текст последней ошибки. Полезную нагрузку часто хранят в JSONB, но для критичных сценариев стоит отдельно определить структуру данных и правила её изменения.

Рабочий цикл состоит из нескольких этапов: приложение помещает задачу в таблицу, исполнитель находит подходящую запись, отмечает её занятой, выполняет работу и сохраняет результат. Если обработчик завершился аварийно, задача не должна навсегда остаться в состоянии "в работе". Для этого используют время блокировки или аренды: после его истечения другой исполнитель может забрать задание повторно.

Как обрабатывать задачи параллельно

При нескольких обработчиках недостаточно просто выполнить запрос `SELECT` и затем обновить статус. Два процесса могут одновременно прочитать одну запись и начать выполнять её. Это создаёт дубликаты и нарушает ожидаемое поведение.

В PostgreSQL для конкурентного выбора задач применяют блокировки строк, в частности `FOR UPDATE SKIP LOCKED`. Обработчик блокирует найденные записи, а остальные процессы пропускают их и выбирают другие. Такой подход позволяет нескольким исполнителям работать параллельно без предварительной координации через отдельный сервис.

Обычно выбор и перевод задачи в состояние "в работе" выполняют одной транзакцией. Это сокращает окно, в котором задание может быть захвачено дважды. При этом транзакцию не следует держать открытой всё время выполнения длительной операции: обработчик быстро фиксирует захват задачи, завершает транзакцию, выполняет работу и отдельным запросом сохраняет итоговый статус.

Масштабирование очереди в PostgreSQL

На начальном этапе достаточно нескольких обработчиков и подходящих индексов. Например, индекс может ускорить поиск необработанных задач по статусу и времени, когда их разрешено запускать. Конкретный состав индекса зависит от запроса: лишние индексы замедляют вставку и обновление, поэтому их стоит проверять на реальной нагрузке.

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

Увеличивать пропускную способность можно числом обработчиков, но бесконечно наращивать их количество нельзя. Все они конкурируют за соединения, дисковые операции и блокировки. Если обработчики часто не находят свободных задач, создают чрезмерную нагрузку на базу или мешают обычным запросам приложения, очередь начинает конкурировать с основным трафиком за ресурсы.

Inbox: как защититься от повторной обработки

Повторная доставка и повторный запуск - нормальная ситуация для распределённых систем. Обработчик может выполнить действие, но не успеть записать в базу, что задача завершена. После сбоя задание запустится снова. Полностью исключить подобные случаи сложно, поэтому надёжнее проектировать обработку так, чтобы повтор не приводил к повторному бизнес-эффекту.

Паттерн inbox решает часть этой задачи. Вместе с входящим сообщением приложение сохраняет его уникальный идентификатор в таблице полученных сообщений. Запись идентификатора и изменение бизнес-данных выполняются в одной транзакции. Если сообщение с тем же ключом поступит повторно, приложение обнаружит уже обработанный идентификатор и не выполнит операцию второй раз.

Inbox особенно полезен, когда сообщения приходят из внешней системы или передаются через брокер. Он не гарантирует, что код никогда не запустится повторно, но помогает обеспечить идемпотентность бизнес-операции. Для этого идентификаторы должны быть действительно уникальными, а срок хранения обработанных сообщений - достаточным для возможных повторов.

PostgreSQL, RabbitMQ и Kafka: в чём различия

PostgreSQL удобен, когда очередь тесно связана с данными приложения, а объём сообщений умеренный. Запись задачи и изменение бизнес-состояния можно выполнить в одной транзакции, что упрощает согласованность. Не нужно поддерживать отдельный брокер, но очередь делит ресурсы с базой и требует внимательного контроля за таблицами, индексами и блокировками.

RabbitMQ - брокер сообщений, ориентированный на маршрутизацию и доставку заданий потребителям. Он предлагает механизмы подтверждения обработки, повторной доставки и распределения сообщений между очередями. Это подходящий выбор для фоновых задач и обмена сообщениями между сервисами, когда возможностей таблицы PostgreSQL уже недостаточно или брокерные функции нужны с самого начала.

Kafka рассчитана прежде всего на потоковую передачу и хранение больших последовательностей событий. Сообщения записываются в упорядоченные разделы, а потребители могут читать поток независимо друг от друга и возвращаться к прежним позициям. Kafka хорошо подходит для событийной архитектуры, аналитических потоков и высоких объёмов данных, но требует другого способа мышления: это не просто таблица заданий, которую исполнитель удаляет после выполнения.

Когда пора выбрать отдельный брокер

Ориентироваться только на число сообщений в секунду недостаточно. Важны длительность задач, размер полезной нагрузки, допустимая задержка, число потребителей и влияние очереди на основную базу. Если PostgreSQL остаётся стабильным, а очередь проста и прозрачна, перенос может добавить больше операционных забот, чем пользы.

Переход на RabbitMQ или Kafka становится разумным, когда очередь заметно нагружает базу, нужны независимое масштабирование потребителей, сложная маршрутизация, длительное хранение событий или подключение множества систем. Перед миграцией стоит определить гарантии доставки, правила повторов, обработку "ядовитых" сообщений и требования к порядку. Эти решения важнее выбора конкретной технологии: именно они определяют, насколько надёжно система поведёт себя при сбоях и росте нагрузки.