Я разрабатываю приложение с различными типами уведомлений. Примеры уведомлений:
- Сообщение создано
- Объявление отправлено
- Объявление одобрено
Я хотел бы связать все это с SignalR, чтобы любые подключенные клиенты получали обновления в режиме реального времени.
Что касается архитектуры - прямо сейчас приложение полностью находится в рамках единого решения, размещенного на веб-сайте Azure. Триггеры для каждого из этих типов уведомлений находятся в этом приложении.
При срабатывании триггера я хотел бы сообщить signalR: «Привет, отправьте это сообщение следующим клиентам» вместе со списком идентификаторов пользователей. Я предполагаю, что можно идентифицировать подключенных клиентов на основе 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. Это доставляет мне дискомфорт, потому что это означает, что я должен нажимать эту красную линию на диаграмме для каждого срабатывания триггера, что - даже если выполняется асинхронно - заставляет меня беспокоиться о производительности и надежности.
Какова рекомендуемая архитектура для масштабируемой и производительной широковещательной передачи сообщений SignalR? Производительность является наивысшим приоритетом, за ней следует стоимость.
Бонусный вопрос:
- Что делать, если одни сообщения имеют более высокий приоритет, чем другие? Следует ли использовать две очереди, одна из которых всегда проверяется раньше другой?
