SignalR scaleout с лазурным сценарием для чата

Question

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

Я хочу масштабировать сервер SignalR вместе с веб-ролями, чтобы обрабатывать тяжелую загрузку пользователя. Несмотря на то, что документация SignalR не рекомендует использовать предварительно выработанные методы масштабирования SignalR с использованием объединительной платы (Redis, Service bus) для таких случаев, когда количество сообщений увеличивается по мере подключения большего числа пользователей (или в сценарии, зависящие от пользовательского события). В нем явно указывается: «Клиент-клиент» (например, чат): в этом случае объединительная плата может быть узким местом, если количество сообщений масштабируется с количеством клиентов, то есть, если скорость сообщений растет пропорционально больше клиентов присоединяются ».

Вопрос: Кто-нибудь знает любой заказ масштабного решения для такого высокочастотного случая, который не толкнуть сообщения каждого экземпляра сервера или другого масштабного решения?

Уже смотрел всюду в документах SignalR и связанных с ними видео, но не мог найти ничего, кроме слова «filter-bus», которое не было объяснено, что это такое и как его следует использовать.

Answer 1

Я сам это понял: Основная идея - сродство к серверу/липкие сессии.

Каждый экземпляр веб-роли действует как автономный сервер SignalR. В первое время подключения я позволяю балансировщику нагрузки Azure выбирать любой экземпляр веб-роли и сохранять IP-адрес этого экземпляра веб-роли с идентификатором клиента на карте. Если есть другой запрос на подключение, поступающий от одного и того же клиента (например, после обновления страницы), я проверяю IP-адрес текущего экземпляра роли и, если он соответствует записи в карте, тогда я разрешаю этому, иначе я отключу клиента и подключу его к правильный экземпляр веб-роли.

Каждый экземпляр рабочей роли также действует как клиент SignalR .net и подключается ко всем доступным серверам SignalR (все экземпляры веб-роли). Перед отправкой сообщения на сервер SignalR (веб-роль) я просматриваю карту, чтобы определить правильный экземпляр сервера SignalR (в зависимости от предполагаемого получателя JS).

Преимущества:

• Там нет необходимости обратной плоскости технологии (и, следовательно, без задержек в доставке сообщений).

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

• Простой в применении.