Шаблон для механизма отката в системе клиент-сервер

Question

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

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

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

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

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

Answer 1

Я не помню, чтобы это описывалось в литературе, но шаблон, который я заметил для таких задач, сосредотачивается на "очереди планирования" - способ осуществления различных вещей (== get функции или методы, вызываемые обратно) ) в определенное время, если не было отменено ранее (например, стандартный библиотечный модуль Python * sched). Когда вы отправляете (асинхронный) запрос на сервер, вы также планируете событие тайм-аута на X секунд; либо объект запроса знает идентификатор запланированного тайм-аута (чтобы отменить его, если запрос будет удовлетворен до этого), либо также поддерживается набор ожидающих запросов (поэтому тайм-аут знает, когда он на самом деле не нужен), что является хорошим Идея в любом случае, поскольку она облегчает обработку «тайм-аутов, которые действительно означают это», см. ниже.

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

Когда происходит событие повтора и т. Д. И т. Д. Если новые запросы поступают в то время, когда система приостановлена, они направляются прямо в корзину для повторных попыток.

Хотя я не могу найти описанную модель, но, возможно, она есть в Отличная книга Шмидта ... в любом случае, настоятельно рекомендуется читать! -)