Управление подключением SignalR в веб-ферме

Question

Мы используем SignalR в крупномасштабном веб-приложении. Мы развернули несколько веб-серверов, обрабатывающих соединения signalR. У нас есть встроенная объединительная плата Redis, у меня есть следующий вопрос: SignalR делает три вызова на сервер: 1) ведет переговоры, 2) подключается и 3) запускается. Если у нас есть веб-ферма за балансировщиком нагрузки, и эти три вызова заканчиваются на трех разных серверах, будет ли состояние соединений повреждено на всех трех серверах? Что произойдет в этом сценарии? Я не говорю о доставке сообщений.

Более конкретно:

1. Будет ли второй веб-сервер будет в состоянии понять ConnectionID производимого вести переговоры вызова?

2. Что происходит, когда физическое соединение (websockets) установлено на другом сервере, а затем стартовый вызов переходит на другой сервер ?

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

Вопрос, который я уже прошел, чтобы получить ответ: SignalR connection affinity in web-farm scenario

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

Answer 1

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

Наш сценарий в режиме реального времени (т. Е. Сообщения чата). Сервер будет уведомлять клиента в любое время, когда другой пользователь входит в систему, отсоединяется и т.д.

Технология стека ниже:

Клиент: AngularJS App

CDN: обслуживание статических ресурсов (HTML, CSS, изображения)

балансировки нагрузки: установка в лазури

Несколько WebApps: работает ASP.NET ядро ​​

Multiple SQL Server базы данных: зеркальное отображение

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

• Пользователи аутентифицируются с использованием маркерного механизма (OAuth в нашем случае). Вся информация пользователя (идентификатор пользователя и т. Д.) Зашифровывается в его токен.

• Соединение установлено и направлено на любое из запущенных веб-приложений.

• Webapp сохраняет информацию о подключении в таблице базы данных.

• Webapp извлекает всех «друзей» пользователей, у которых есть соединение в базе данных.

• Webapp отправляет список обратно клиенту.

• Всякий раз, когда пользователь отключается, webapp получает событие разъединения и удаляет базу данных формы.

• Компания Whevenver повторно подключается, webapp добавляет соединение обратно и отправляет пользователю текущий список подключений/клиентов в Интернете.

Клиент должен поддерживать, в каком состоянии он находится, и как реагировать на обновления в списках клиентов.

Этот подход аналогичен описанному в ответе, который вы опубликовали в своем вопросе.

Я считаю, что принципиальная концепция здесь - объединительная плата. Он сохраняет состояние, а не просто передает его вокруг серверов.

Связанное сообщение в блоге здесь может помочь: https://docs.microsoft.com/en-us/aspnet/signalr/overview/guide-to-the-api/mapping-users-to-connections

(Взгляните на сценариях «Более один сервера»)