хрень получается?
Вроде норм получается) Но для прода лучше кафка или реббит
смотря про какие объемы речь
Мы примерно так и используем, но есть два нюанса: 1. Клиент, выполнивший listen, должны оперативно разбирать очередь, т.к. её размер ограничен (хоть и довольно большой) 2. Нужна дублирующая структура (табличка), из которой можно будет забирать инфу по необработанным элементам очереди, т.к. если ожидающий клиент по какой-то причине отключится, то отправленные notify-и отправятся в никуда, т.е. эта очередь не персистентная
хрень, лучше через таблицу, и обрабатывать проще потом
Через таблицу лучше - там хоть падения обработчиков / перезапуски можно накрутить. А если вам «чатик», то, наверное, стоит глянуть на https://github.com/supabase/realtime (держа в уме, что это бета)
Таблица и очередь в listen/notify решают *разные* задачи. Если делать очередь на таблице, придётся её поллить постоянными селектами и получите минимальную гарантированную латенси даже пустой очереди равную периоду между запросами. listen/notify решает эту проблему и в комбинации с табличками позволяет снизить латенси до времени ipc на сервере БД. Точнее, если у вас используется не libpq, а, например, стандартный jdbc-клинт, придётся всё равно запросы слать, но это будут пустые запросы, не нагружающие сервер.
Обсуждают сегодня