Приложение в реальном времени на Microsoft Azure

Question

Я работаю над приложением в реальном времени и создаю его на Azure.

Идея состоит в том, что каждый пользователь сообщает что-то о себе, и все другие пользователи должны видеть это немедленно (они опрашивают службу каждые секунды или около того для получения новой информации)

Мой подход на данный момент заключался в использовании веб-роли для службы REST WCF, когда я выполняю всю запись в БД (SQL Azure) без рабочей роли, чтобы она была записана немедленно.

Я пришел к выводу, что, возможно, использование Рабочей роли и Очереди для написания может быть гораздо более масштабируемым, но может повлиять на сторону службы в реальном времени. (Рабочая роль может не сразу взять работу из очереди)

Это правда? Как мне решить эту проблему?

Спасибо

Answer 1

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

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

Вы можете заглянуть в кэш для буферизации последних пользовательских обновлений, поэтому при опросе ваша служба читает из кэша, а не из SQL Azure. Это может помочь при увеличении объема информации.

Answer 2

Вы можете взглянуть на SignalR, он не поддерживает готовые сценарии фермы, но должен иметь возможность работать с использованием любых внутренних вызовов конечной точки для обновления каждого экземпляра с использованием служебной шины Azure. или используя кэш AppFabric. Таким образом, вы получаете сценарий Push, а не сценарий Pull, поэтому вам не нужно опрашивать конечные точки на предмет возможных обновлений.