Как использовать ServiceStack Redis в веб-приложении, чтобы воспользоваться парадигмой pub / sub

Question

Меня интересует парадигма Pub / Sub , чтобы обеспечить систему уведомлений (например, как Facebook), особенно в веб-приложении, в котором есть издатели (в нескольких веб-сайтах). приложения на одном веб-сервере IIS) и один или несколько подписчиков, отвечающие за отображение в Интернете уведомлений для фронтального пользователя.

Я обнаружил, что Redis, кажется, отличный сервер, который предоставляет интересные функции: кэширование (например, Memcached), Pub / Sub, queue.

К сожалению, я не нашел никаких примеров в веб-контексте (ASP.NET, с Ajax / jQuery), кроме WebSockets и NodeJS, но я не хочу использовать их (слишком рано). Я предполагаю, что мне нужен процесс (подписчик), который получает сообщения от издателей, но я не вижу, как это сделать в веб-приложении (pub / sub отлично работает с юнит-тестами).

РЕДАКТИРОВАТЬ: в настоящее время мы используем .NET (ASP.NET Forms) и опробовать библиотеку ServiceStack.Redis (http://www.servicestack.net/)

Answer 1

На самом деле Redis Pub / Sub достаточно хорошо справляется с этим сценарием, так как Redis является асинхронным неблокирующим сервером, он может дешево удерживать многие соединения и хорошо масштабируется.

Сальваторе (он же Мистер Редис :) описывает O (1) сложность времени операций публикации и подписки :

Вы можете рассмотреть работу подписаться / отписаться как работа в постоянном времени, O (1) для обоих подписываться и отписываться (на самом деле PSUBSCRIBE делает больше работы чем это, если вы подписаны уже много моделей с тот же клиент).

...

По поводу памяти, похоже или меньше чем тот, который используется ключом, так что вы не должно быть проблем с подпиской на миллионы каналов даже в маленький сервер.

Таким образом, Redis более чем способен и предназначен для этого сценария, но проблема, как указал Том, для того, чтобы поддерживать постоянное соединение, потребует длительных подключений (так называемый http-push / long-poll) и каждого активного пользователя. возьму свою нить. Удержание потока не очень хорошо для масштабируемости, и с технической точки зрения было бы лучше использовать неблокирующий http-сервер, такой как Manos de Mono или node.js , которые являются асинхронными и не блокировка и может справиться с этим сценарием. Примечание: WebSockets более эффективен для уведомлений в режиме реального времени по HTTP, поэтому в идеале вы должны использовать его, если браузер пользователей поддерживает его, и переходить на обычный HTTP, если они этого не делают ( или использовать Flash для WebSockets на клиенте). ).

Таким образом, здесь не масштабируется Redis или его Pub / Sub, а число одновременных подключений, которое использует многопоточный HTTP-сервер, такой как IIS или Apache, при этом вы можете поддерживать достаточное количество одновременных пользователей с IIS ( в этом посте предлагается 3000 ), и поскольку IIS является узким местом, а не Redis, вы можете легко просто добавить дополнительный IIS-сервер в смесь и распределить нагрузку.

Answer 2

Для этого приложения я настоятельно рекомендую использовать SignalR , который представляет собой .Net-инфраструктуру, позволяющую в реальном времени передавать подключенные клиенты.

Answer 3

Публикация / подписка Redis не предназначена для этого сценария - она ​​требует постоянного подключения к redis, которое у вас есть, если вы пишете рабочий процесс, но не при работе с веб-запросами без сохранения состояния.

Система публикации / подписки, которая работает для конечных пользователей через http, требует немного больше работы, но не слишком много - самый простой подход - использовать отсортированный набор для каждого канала и записывать время, когда пользователь последний раз получал уведомления. Вы также можете сделать это с помощью списка подписчиков записи для каждого канала и записывать в список входящих каждого из этих пользователей всякий раз, когда добавляется уведомление.

С помощью любого из этих методов пользователь может очень быстро получить свои новые уведомления. Это будет форма опроса, а не настоящие push-уведомления, но вы не собираетесь уходить от этого из-за природы http.

Технически вы можете использовать redis pub / sub с длительными http-соединениями, но если каждому пользователю нужен собственный поток с активными redis и http-соединениями, масштабируемость будет не очень хорошей.