Общие сведения об отключении клиента и повторном подключении

Постоянные подключения, такие как те, которые поддерживаются через WebSockets, по сути, подвергаются прерываниям. Хотя служба Azure SignalR предназначена для обеспечения высокой надежности и масштабируемости, случайные отключения клиентов являются реальностью, для которых должны учитываться все приложения, подключенные к Интернету.

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

Руководство высокого уровня

1. Прерывания подключения неизбежны

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

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

Сделать процесс повторного подключения простым и необременительным

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

Просмотрите текущий поток, чтобы определить, действительно ли все операции, связанные с активным подключением WebSocket, зависят от него. Во многих приложениях, таких как уведомления, аукционы, чат, панели мониторинга или совместная работа, повторное подключение происходит быстро (обычно в течение нескольких секунд) и оказывает небольшой эффект. Для приложений, использующих конфиденциальные или транзакционные данные, поток повторного подключения может быть тяжелее, но рассмотрите, можно ли отделить определенные операции и выполнять с помощью REST API вместо постоянного подключения.

3. Эффективная обработка повторного подключения

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

Используйте повторное подключение с сохранением состояния при необходимости

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

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

При повторном подключении с новым идентификатором подключения

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

Необходимо учесть следующие моменты.

• Повторное присоединение к группам, в которых клиент ранее состоял,
• Восстановление состояния сеанса (например, подписок) из надежного хранилища;
• Обработка пропущенных сообщений путем получения их из хранилища на уровне приложения или журнала событий, если гарантия доставки сообщений важна.

4. Управляйте нагрузкой во время крупномасштабных повторных подключений

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

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

5. Внимательно рассмотрите варианты транспорта и модели размещения

• Длинные опросы и событияServer-Sent (SSE) являются резервными вариантами для сред без поддержки WebSocket, но обычно они не повышают надежность.
• Самостоятельное размещение SignalR обеспечивает полный контроль над временем обслуживания и управлением жизненным циклом, но также сдвигает операционные и масштабируемые обязанности в вашу команду.
• Бессерверный режим службы Azure SignalR не снижает вероятность или влияние падений подключений, так как отключение — это поведение на уровне сети на стороне клиента.

Отключения во время обслуживания сервиса

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

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

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