Использует ли redis pub/sub model постоянные соединения для redis?

В веб-приложении, если мне нужно записать событие в очередь, я бы сделал соединение с redis для записи события.

Теперь, если мне нужен другой бэкэнд-процесс (скажем, демона или задание cron) для обработки или реакции публикации события в redis, мне нужно постоянное соединение?

Немного смущает, как этот паб/подпроцесс работает в веб-приложении.

Ответы

Ответ 1

В основном в Redis есть две разные модели обмена сообщениями:

  • Пожар и забудьте/от одного до многих: Pub/Sub. Во время сообщения PUBLISH-ed все подписчики получат его, но это сообщение будет потеряно навсегда. Если клиент не был подписан, нет способа вернуть его.
  • Сохраняющиеся очереди/один к одному: списки, возможно, используемые с такими командами блокировки, как BLPOP. В списках у вас есть продюсер, который вставляет список, а один или многие пользователи ждут элементы, но одно сообщение будет доступно только одному из ожидающих клиентов. Со списками у вас есть настойчивость, и сообщения будут ждать, пока клиент вытолкнет их, а не исчезнет. Так что даже если никто не слушает, есть отставание (такое же большое, как и ваша доступная память, или вы можете ограничить отставание с помощью LTRIM).

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

  • LPUSH/RPUSH, RPOP/LPOP, BRPOP/BLPOP
  • ПУБЛИКАЦИЯ, ПОДПИСАТЬСЯ, ПОДПИСАТЬСЯ

Doc для этих команд доступен по адресу redis.io

Ответ 2

Я не совсем уверен, но я считаю, что да, pub/sub требует постоянного соединения.

В качестве альтернативы я бы заглянул в resque и как он справляется с этим. Вместо того, чтобы использовать pub/sub, он просто добавляет элемент в список в redis, а затем все задания демонов или cron могут использовать команду lpop для получения первой.

Извините за предоставление псевдо ответ, а затем за вилку.

Ответ 3

Используйте BLPOP вместо LPOP