Комментарии 17
Есть сравнительные данные о производительности, условно говоря - какое сообщений в секунду потянет kafka, rmq и ваше решение на одинаковом железе?
Если уж оракл не справляется со своим advanced queue на серьезных нагрузках, то не стоит надеяться что постгрес справится. Для небольших монолитов идущих в сторону распила, но не готовых ввязываться в распределенный блудняк может и подойдёт. Но предел производительности БД очевиден особенно при пиковых вбросах. Делить функциональную основную бизнес нагрузку с нагрузкой по очередям на одном сервере такое себе. А стоимость железа под БД обычно выше чем стоимость железа под кластерные брокеры. Короче есть плюсы, но есть и масса минусов, особенно для растущих по нагрузке баз.
Краткий пересказ статьи: изобрели аналог MS SQL Service Broker для PostgreSQL 😏😏😏
Подскажите пожалуйста, какие есть планы на шардирование этих очередей? Будет ли этот функционал только в PostgresPro или появится и в shardman тоже? Какой выбран протокол взаимодействия с очередями?
P.S.: ваш пример в ачале статьи с транзакионным разрывом между брокером и бд некорректен: все зависит от последовательности "коммитов", при правильной последовательности мы таску\сообщение не теряем, но должны быть готовы к обработке дубля. Что может быть дешевле 2pc или просто остается единственным вариантом, когда 2pc не возможен (kafka+db).
По расширению функциональности на shardman, всё будет зависеть от потребностей клиентов.
P.S.: ваш пример в ачале статьи с транзакионным разрывом между брокером и бд некорректен: все зависит от последовательности "коммитов", при правильной последовательности мы таску\сообщение не теряем, но должны быть готовы к обработке дубля. Что может быть дешевле 2pc или просто остается единственным вариантом, когда 2pc не возможен (kafka+db).
Суть примера — показать фундаментальный разрыв атомарности между брокером и БД без 2PC: outbox/CDC и «сначала коммит БД, затем публикация» снимают риск потери, но оплачиваются сложностью идемпотентности, дедупликации и возможными повторными доставками. pgpro_queue решает это иначе: сообщение и бизнес‑данные находятся в одной транзакции СУБД, где откат гарантированно возвращает сообщение в очередь, то есть нет разрыва и нет необходимости отдельно проектировать анти‑дубль логику на уровне интеграции.
Рассогласование данных. Представьте сценарий: приложение отправляет сообщение в RabbitMQ и начинает транзакцию в базе данных. Сообщение уже ушло в брокер, но в момент коммита транзакции в БД происходит сбой. Результат — рассогласование:...
А почему взяли заранее калеченый пример? Есть же паттерн outbox, есть cdc (с дебезиум). Почему бы не сравнить с ними?
откровенно говоря само утверждение авторов из профессионального постгреса спорное, есть распределенные (многофазные) транзакции для java чтоб сделать единый комит для базы и очереди, все это стандартизировано было еще лет 20 назад (если не 30) и продавалось заинтересованным лицам, тк проблема очевидная.
а " паттерн outbox, есть cdc (с дебезиум) " это решение что называется "для бедных". второй раз за месяц замечаю что авторы тут словно в танке сидят
1) для этого надо покупать платный Postgres Pro ?
2) есть такие же очереди и для бесплатного PostgreSQL :-)
тоже через расширения устанавливаются.
По описанию внутренне похож на mbus, очередь так же хранится на таблицах. В mbus есть проблема, что при большом объеме (количесвтенном) передаваемых сообщений деградирует скорость чтения сообщений из-за большого числа мертвых записей (т.е. их удалили, но они остались на диске, автовакум не пришел еще или не может выполнить очистку). Как решили подобную проблему?
Эта проблема решается стандартными, но целенаправленно настроенными средствами самого PostgreSQL, так как очередь представляет собой обычную таблицу. Предполагается, что для высоконагруженных таблиц-очередей администратор базы данных настроит более агрессивный autovacuum, чтобы минимизировать раздувание таблиц и поддерживать высокую производительность чтения.
Для небольшого потока событий в определенных условий (переходный период и так далее) - в принципе можно. А целом - надо все-же использовать выделенные решения типа Kafka.
Вы правы, Kafka незаменима для больших потоков событий, но pgpro_queue решает другую ключевую задачу — обеспечение 100% транзакционной надёжности. В отличие от внешних брокеров, оно гарантирует атомарность операции "задача + данные", полностью исключая риск рассогласования при сбоях. Поэтому для критически важных систем, где цена ошибки высока, это не компромиссное, а стратегически верное решение для упрощения архитектуры и повышения её предсказуемости.
Можно дождаться фиксации транзакции, выполнить запрос данных и отправить их в брокер, а сам брокер разошлет данные всем подписчикам.
Так можно, но это не устраняет транзакционный разрыв между БД и брокером. Последовательность «сначала фиксация БД, затем публикация» с идемпотентностью снижает риск потери, но допускает дубли и требует дополнительной инфраструктуры (outbox/CDC, мониторинг, повторная доставka). В pgpro_queue сообщение и данные живут в одной транзакции: при откате оно автоматически возвращается в очередь, без внешних механизмов согласования.
А можно расшифровать кто страдает при таком решении? Сервер БД или Java сервер?
Как уже говорили есть есть готовые решения с распределенными транзакциями (там решение основано на двухфазном комитте). Есть паттерны которые нивелируют разрыв транзакций. У них есть готовые решения, известные и описанные проблемы.
Чем ваше решение лучше например запуска JMS брокера в одной JVM с бизнес приложением и пере использованием одной транзакции?
Очереди сообщений в Postgres Pro: отказ от внешних брокеров ради транзакционной надёжности