Аргументы против перегруженности брокерами
Специализированные брокеры сообщений, такие как SQS, Kafka и RabbitMQ, создают значительные, часто скрытые, операционные накладные расходы. Вам приходится управлять отдельной инфраструктурой, неся затраты на подготовку, развертывание, мониторинг и масштабирование отдельных сервисов. Это увеличивает сетевую задержку и критически повышает когнитивную нагрузку на разработчиков, занимающихся интеграцией и отладкой множества распределенных систем, что привносит в ваш стек неоправданную сложность.
Ваша существующая база данных Postgres предлагает надежную и проверенную альтернативу, устраняющую необходимость в дополнительных брокерах. Построенный на принципах ACID-совместимости и проверенной временем транзакционной мощности, Postgres обеспечивает надежный фундамент для организации очередей, гарантируя целостность данных даже при сбоях. Он легко справляется с миллионами строк и тысячами запросов в секунду; например, тест на 2 CPU и 2 ГБ RAM показал обработку 100 000 сообщений за 9 секунд, в среднем 11 100 сообщений в секунду.
PGMQ формализует этот мощный паттерн в виде легковесного и простого расширения. Оно предоставляет API в стиле SQS непосредственно внутри Postgres, позволяя создавать очереди, отправлять сообщения с опциональными задержками и потреблять их с использованием таймаутов видимости (VT) для гарантии доставки ровно один раз. Это означает, что вы получаете полнофункциональную очередь сообщений с клиентскими библиотеками для Rust, Python и TypeScript, не добавляя в свой стек ни одного нового сервиса.
От нуля до очереди за 5 строк SQL
Создавайте очереди с помощью чистого SQL. Вызовите pgmq.create('my_queue'); каждая очередь становится отдельной таблицей Postgres. Отправляйте сообщения с помощью pgmq.send('my_queue', '{"job_id": 123}'). Это встраивает сообщения в формате JSON непосредственно в Postgres, упрощая вашу модель данных.
Реализуйте отложенную доставку с помощью pgmq.send(). Добавьте параметр delay (например, pgmq.send('my_queue', '{"task": "future"}', 30)). Сообщение попадает в очередь, но остается недоступным для обработки в течение 30 секунд, что позволяет планировать задачи без использования внешних cron-сервисов.
Потребляйте сообщения через pgmq.read('my_queue', 30, 1). Критически важный параметр vt (таймаут видимости) делает прочитанные сообщения невидимыми на указанный срок (например, 30 секунд). Это обеспечивает доставку ровно один раз: ни один другой воркер не сможет обработать то же самое сообщение в течение активного окна. Если сообщение не будет обработано или удалено в течение VT, оно снова появится в очереди.
После обработки удаляйте сообщения. Используйте pgmq.delete('my_queue', message_id) для безвозвратного удаления сообщения. Альтернативно, pgmq.archive('my_queue', message_id) удаляет сообщение из активной очереди и перемещает его в специальную архивную таблицу, предоставляя исторический лог для аудита или повторной обработки.
Но действительно ли это масштабируется?
"Но это не масштабируется", — скажете вы. Это распространенный аргумент против использования баз данных в качестве очередей. Однако Postgres легко справляется с миллионами строк и тысячами запросов в секунду. PGMQ использует эту встроенную возможность, превращая кажущуюся слабость в преимущество для распределенных приложений.
Недавний стресс-тест подтвердил производительность PGMQ на ограниченных ресурсах. Исследователи развернули Docker-контейнер всего с 2 CPU и 2 ГБ RAM. Затем они отправили 100 000 сообщений в очередь PGMQ. Эта конфигурация повторяет типичные среды реальных сервисов, что делает результаты весьма показательными.
Сто параллельных воркеров обработали все 100 000 сообщений всего за 9 секунд. Каждый воркер считывал, регистрировал и удалял сообщения пакетами. Это соответствует совокупной пропускной способности, превышающей 11 100 сообщений в секунду. Для получения подробной документации и дополнительных примеров обратитесь к официальному репозиторию Postgres Message Queue (PGMQ).
Такая производительность однозначно опровергает миф о том, что Postgres «не масштабируется», практически для любого реального приложения. PGMQ доказывает, что Postgres является не просто жизнеспособным, но и высокопроизводительным решением в качестве очереди сообщений, устраняя эксплуатационные расходы на специализированные брокеры для большинства сценариев использования. Упрощайте свою инфраструктуру.
Нравится статья? Получайте такие каждое утро на почту.
одно письмо в день · отписка в два клика · без сторонних трекеров
Интеграция PGMQ в ваше приложение
Интегрируйте PGMQ непосредственно в стек вашего приложения. Выйдите за рамки чистого SQL с помощью надежных клиентских библиотек для популярных языков программирования. Официальная поддержка обеспечивает интеграцию с Python и Rust, предлагая идиоматические интерфейсы. Библиотеки, созданные сообществом, расширяют возможности PGMQ для Ruby и различных вариантов TypeScript, включая бесшовную работу с Prisma.
Создавайте продюсеры с минимальным количеством кода. Продюсер на Python отправляет сообщение с помощью простого вызова send(), указывая имя очереди и JSON-полезную нагрузку. Это зеркально отображает SQL-команду pgmq.send(), абстрагируя взаимодействие с базой данных для вас.
Воркеры эффективно потребляют сообщения. Используйте функцию read() клиентской библиотеки для получения пакета сообщений с учетом таймаута видимости (visibility timeout, VT). После обработки вызовите delete() или archive(), чтобы удалить сообщения, обеспечивая однократную доставку (exactly-once delivery) и предотвращая повторную обработку. Этот шаблон отлично справляется с высоконагруженными задачами.
Объединение уровней данных и обмена сообщениями внутри Postgres упрощает вашу инфраструктуру. Устраните эксплуатационные расходы на отдельные брокеры сообщений, сократив сетевые задержки и когнитивную нагрузку. Эта консолидация оптимизирует разработку, тестирование и развертывание, создавая более надежную и поддерживаемую систему.
Часто задаваемые вопросы
Что такое PGMQ?
PGMQ (Postgres Message Queue) — это легковесное расширение для PostgreSQL, которое реализует функциональность очереди сообщений непосредственно внутри базы данных, предлагая альтернативу таким сервисам, как AWS SQS, RabbitMQ или Kafka.
Как PGMQ обеспечивает однократную доставку?
PGMQ использует «таймаут видимости». Когда сообщение считывается, оно становится невидимым для других потребителей на определенный период. Потребитель должен удалить или архивировать сообщение в течение этого времени. Если этого не происходит, сообщение снова становится доступным для обработки другим потребителем, что предотвращает потерю данных.
Может ли PGMQ справиться с нагрузкой промышленного уровня?
Да. Бенчмарки показывают, что PGMQ может обрабатывать более 11 000 сообщений в секунду на скромном оборудовании (например, контейнере с 2 CPU). Этого более чем достаточно для многих высоконагруженных распределенных приложений.
В чем главное преимущество использования Postgres в качестве очереди сообщений?
Основное преимущество — упрощение инфраструктуры. Используя существующую базу данных, вы уменьшаете количество зависимостей, снижаете эксплуатационные расходы и упрощаете весь технологический стек, не жертвуя производительностью в большинстве распространенных сценариев.