обнаружение сбоев в клиент-серверных системах (распределенное) - PullRequest
Новая
       32

обнаружение сбоев в клиент-серверных системах (распределенное)

1 голос
/ 11 ноября 2010

Предположим, что в распределенной системе связи клиент и сервер обмениваются данными через канал без состояния.
Клиент отправляет запросы на сервер, а сервер выполняет обработку и ведет внутренние записи для каждого клиента.
Сервер отправляет обратно уведомленияклиенты, когда с системой происходят различные события, по мере необходимости.
Механизм уведомления зависит от внутренних записей.
Мой вопрос: каков стандартный подход в распределенных вычислениях для обработки сбоев клиента?
Т.е. вВ этом контексте предположим, что клиентский процесс падает или просто перезапускается.На сервере все еще есть записи для клиента, но теперь клиент и сервер синхронизированы.В результате клиент получит уведомления в соответствии с записями, созданными до перезапуска.Это нежелательно .
Что такое стандартизированный способ обнаружения сбоев клиента?Например, клиент перезапустился, и предыдущие записи должны быть удалены?
Я думал о периодических обратных вызовах к клиентам, и если клиент недоступен, удалите его записи, но я не уверен, что это хорошая идея. [EDIT] Я думал о обратных вызовах, потому что события периода, отправляемые обратно клиенту, могут иметь очень большие интервалы, и поэтому сбой клиента вскоре не будет заметен

Может ли кто-нибудь помочь в этом?Контекстом моего домена приложения являются веб-сервисы.

Спасибо!

1 Ответ

2 голосов
/ 11 ноября 2010

Стандартный подход варьируется от системы к системе в зависимости от архитектуры и домена. Как сервер узнает, что клиент не работает? Я думаю, что вам не нужны обратные вызовы, так как вы отправляете уведомления и можете обнаружить, что клиент недоступен. Например:

  1. отправить уведомление клиенту;
  2. в случае успеха, перейти к 1;
  3. иначе удалите все уведомления в очереди для клиента, установите флажок, чтобы не собирать события для клиента.

Когда клиент подключен:

  1. снять флаг;
  2. начать отправку уведомлений

Или даже более простой подход:

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

Обновление после оригинального комментария автора

Это сильно зависит от того, как все организовано в вашей системе. Предполагая, что:

  1. Сервер запускает поток (назовем его «агент») для обслуживания клиента, поток для каждого клиента.
  2. Агент завершает работу, когда клиенты правильно завершают сеанс или отключаются.
  3. для каждого клиента установлена ​​личная (которая не используется агентами / клиентами) запись
  4. существует общий список текущих клиентов, который используется другим компонентом (не обычным агентом, назовем его «диспетчер») для распространения записей для клиентов.

решение: 1. сервер запускает агента и регистрирует только что подключенного клиента к списку клиентов. Диспетчер получает уведомление о прибытии нового клиента. 2. агент потребляет записи, пока клиент не подключен. При выключении и / или сбое клиента агенты отменяют регистрацию клиента и очищают набор записей.

Если вещи в вашей системе организованы не так, как описано выше, пожалуйста, предоставьте некоторые подробности.

...