Масштабируемый SignalR + Azure - где поставить SignalR, и должен ли я использовать Azure Queues?

Question

Я разрабатываю приложение, которое имеет различные типы уведомлений. Примеры уведомлений:

• Сообщение Создано
• Листинг Опубликовано
• Листинг Утверждена

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

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

Когда срабатывает триггер, я хотел бы сказать signalR: «Эй, отправьте это сообщение следующим клиентам» вместе со списком userIds. Я предполагаю, что можно идентифицировать подключенные клиенты на основе userId ... и я предполагаю, что процесс send message to clients должен выполняться вне веб-приложения, чтобы не замедлять приложение MVC или не потерять данные в сломанный асинхронный вызов. Первый вопрос - Правильность этих допущений?

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

Предполагая, что это так, это означает, что я могу либо использовать хороший Ол»базы данных Azure SQL в качестве очереди, но мне кажется, что есть некоторые специализированные (и, возможно, дешевле) услуги для обработки очередей сообщений, например, следующим образом:

http://www.windowsazure.com/en-us/develop/net/how-to-guides/queue-service/

Третий вопрос: Если это будет использоваться в качестве механизма массового обслуживания для signalR? Я заинтересован в использовании Redis для кеширования в будущем ... был бы Redis лучше или хуже, чем обслуживание очереди?

Заключительный вопрос:

Я попытался проиллюстрировать предложенную мою архитектуру здесь:

Что я больше всего неясными здесь, как приложение MVC будет знать, когда очереди, или как процессы SignalR будут знать, когда нужно транслировать. Должно ли приложение MVC стоять в очереди, не заботясь о подключенных клиентах? Кажется, это приводит к большому количеству потраченного впустую места в очереди и впустую циклов в рабочих ролях, поскольку очень маленький процент клиентов будет когда-либо подключен.

Единственный другой подход, который я могу представить, - это каким-то образом показать видимость приложения MVC в процессах SignalR, чтобы увидеть, подключен ли клиент ... и если они есть, то Enqueue. Это делает меня неудобным, потому что это означает, что я должен ударить эту красную строку на диаграмме для каждого триггера, который попадает, что, даже если сделано async, заставляет меня беспокоиться о производительности и надежности.

Какова рекомендуемая архитектура для масштабируемого, эффективного трансляции сообщений SignalR? Производительность является главным приоритетом, а за ней следуют затраты.

Бонус вопрос:

• Что делать, если некоторые сообщения имеют более высокий приоритет, чем другие? Должны ли использоваться две очереди, одна из которых всегда проверяется перед другой?

Answer 1

Если вы хотите настроить таргетинг на некоторых пользователей, вам придется придумать механизм, с верхней части головы. Я могу привести пример, если какой-либо пользователь нажимает на страницу, вы можете создать группу для эту страницу и нажмите на всех пользователей этой группы/на этой странице.

Мне непонятно, зачем вам очереди. Обычно пользователи подписываются на некоторые события при попадании на страницу или на некоторые действия, например, присоединяются к комнате чата, а сервер толкает данные, используя эти события/функции, когда это необходимо.

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

Answer 2

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

Затем, где бы ни был запущен триггер, и вы хотите отправлять сообщения пользователям, вам необходимо создать клиент SignalR (.NET или javascript), а затем подключиться к серверу SignalR. Затем вы можете отправить сообщение на сервер SignalR, который, в свою очередь, будет транслироваться для всех других подключенных пользователей. После этого вы можете отключить соединение с сервером SignalR. Таким образом, вам не нужно использовать очереди для связи с ролью SignalR.

А также для отправки сообщений определенным пользователям вы можете сохранить идентификатор сокета вместе со своим идентификатором пользователя в таблице (следует хранить хранилище таблицы azure), когда они подключаются к серверу SignalR. Затем, используя идентификатор сокета, вы можете отправлять сообщения конкретному пользователю.