Для приготовления асинхронных уведомлений из PostgreSQL в websocket нам понадобится сам nginx и его плагины postgres, push-stream, set-misc. (Я дал ссылки на свои форки, т.к. делал некоторые изменения, которые пока не удалось пропихнуть в оригинальные репозитории. Можно также воспользоваться готовым образом.)

Для подключения клиентов к nginx по websocket создадим

location =/websocket {
    push_stream_subscriber websocket; # принимаем клиентов по websocket
    push_stream_channels_path $arg_id; # задаём имя websocket канала из аргумента id
    push_stream_websocket_allow_publish on; # позволяем клиентам что-нибудь публиковать в канал
    push_stream_client_subscribed_request /subscribe; # задаём что будет происходить при подключении клиента
    push_stream_client_unsubscribed_request /unsubscribe; # задаём что будет происходить при отключении клиента
    push_stream_client_publish_request /publish; # задаём что будет происходить при публикации клиентом в websocket
}

При подключении клиента к websocket начинаем слушать асинхронные уведомления в PostgreSQL

location =/subscribe {
    internal;
    postgres_pass ngx; # задаём подключение к PostgreSQL
    set_quote_json_str $channel $arg_id; # экранируем имя канала
    postgres_query "listen $channel"; # начинаем слушать асинхронные уведомления
}

При отключении клиента от websocket прекращаем слушать асинхронные уведомления в PostgreSQL

location =/unsubscribe {
    internal;
    postgres_pass ngx; # задаём подключение к PostgreSQL
    set_quote_json_str $channel $arg_id; # экранируем имя канала
    postgres_query "unlisten $channel"; # прекращаем слушать асинхронные уведомления
}

При публикации клиентом в websocket выполняем что-нибудь

location =/publish {
    internal;
    postgres_pass ngx; # задаём подключение к PostgreSQL
    postgres_query "select now()"; # выполняем команду в PostgreSQL и возвращаем результат клиенту через websocket
}

Также, можно просто послать что-нибудь клиенту в websocket

location =/publisher {
    allow 127.0.0.1/16; # разрешаем только локальные подключения
    deny all; # запрещаем все остальные подключения
    push_stream_channel_info_on_publish off; # не публикуем в информационные кананлы информацию о публикации
    push_stream_publisher; # включаем публикацию
    push_stream_channels_path $arg_id; # задаём имя websocket канала из аргумента id
}

Комментарии (4)


  1. alexesDev
    19.06.2019 09:23

    Я пользуюсь событиями в pg по мелочи, там где не страшно потерять событие.


    Есть данные несколько события pg надежнее событий, к примеру, nats? nats потому что тоже простой как палка.


    1. RekGRpth Автор
      19.06.2019 14:10

      Для надёжности я сделал планировщик


      1. alexesDev
        19.06.2019 15:23

        А чем он отличается от отдельно процесса с таким кодом? Или pgq?


        while (true) {
          select * from tasks where status = 'pending';
          ... do work ...
          update tasks set status = 'completed' where id = ?
        }


        1. RekGRpth Автор
          19.06.2019 15:36

          Планировщик работает на серверной стороне базы, тогда как этот код и pgq — на клиентской.