Шаблон повторов, как определить тип ошибки в PHP - PullRequest
0 голосов
/ 15 января 2020

Я хочу реализовать шаблон Retry в PHP (Guzzle), чтобы определить, нужно ли мне повторно отправлять запрос в случае сбоя или нет. И в случае необходимости я должен использовать некоторую задержку перед повторной отправкой или нет. ПРИМЕЧАНИЕ: это внутренняя связь служб, и каждая служба находится в группе масштабирования и находится за балансировщиком нагрузки, поэтому мы предполагаем, что целевой URL-адрес является существующим URL-адресом, но по какой-то причине может быть недоступен, также все серверы NGINX

Есть ли рекомендации по выполнению повторных попыток или нет, с задержкой или нет ??

Насколько я знаю, статус 503 означает, что сервер перегружен, поэтому, вероятно, в такая небольшая задержка может помочь дождаться запуска нового экземпляра и помочь распределить нагрузку ???

Что делать в случае ошибки 502/504, также повторите попытку с некоторой задержкой ???

Что делать в случае ошибки 500 ?? В моем понимании 500 должно быть выброшено, когда что-то не так с сервером или логи c в целом, и нам не нужно выполнять повторную попытку ???

Как насчет 400, то же действие, что и если мы получим 500 ??

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

422 Я использую в случае какой-либо ошибки домена или ошибки проверки, но, может быть, сервер может вернуть его в другом случае? Если это только вызвано мной, я могу предположить, что повторная попытка не требуется.

А как насчет других кодов состояния, также есть NGINX специфицированные c коды ???

Я знаю, что, вероятно, мне нужно создать определенную c стратегию повторения для каждого случая URI, но я считаю, что есть некоторые общие / повторно используемые правила.

1 Ответ

0 голосов
/ 15 января 2020

Я получаю такой список:

  • 400 Плохой запрос - нет RETRY
  • 401 Не авторизован - нет RETRY
  • 402 Требуется оплата - нет RETRY
  • 403 Запрещено - нет RETRY
  • 404 Не найдено - как я уже говорил ранее, я предполагаю, что у нас разные 404, если какой-то ресурс не найден, например, пользователь в БД, если 404 страницы не найдены в случае действительно неправильный URL, и не найдена проблема балансировки bz. Поэтому, если какой-то ресурс не найден, мы собираемся отправить некоторые пользовательские данные, в этом случае без RETRY, в других случаях мы собираемся RETRY
  • 405 Метод не разрешен - нет RETRY
  • 406 Недопустимо - нет RETRY
  • 407 Требуется проверка подлинности прокси-сервера - нет RETRY
  • 408 Время ожидания запроса - RETRY
  • 409 Конфликт - RETRY
  • 410 Ушел - нет RETRY
  • 411 Требуется длина - нет RETRY
  • 412 Предварительное условие не выполнено - нет RETRY
  • 413 Слишком большая полезная нагрузка - нет RETRY
  • 414 URI слишком длинный - нет RETRY
  • 415 Неподдерживаемый тип носителя - нет RETRY
  • 416 Диапазон Не удовлетворен - нет RETRY
  • 417 Ожидание не выполнено - нет RETRY
  • 421 неверно направленный запрос - нет RETRY
  • 422 Unprocessable Entity - нет RETRY
  • 423 Locked - RETRY если не указано время и время блокировки Слишком большая
  • 424 Зависимая ошибка - нет RETRY
  • 426 Требуется обновление - нет RET RY
  • 428 Требуется предварительное условие - нет RETRY
  • 429 Слишком много запросов - возможно, повторная попытка RETRY
  • 431 Поля заголовка запроса TooLarge - нет RETRY
  • 451 Недоступно по юридическим причинам - нет RETRY

Таким образом, большинство ошибок 4 ** Client не следует повторять.

Ошибки 5 ** Servers, которые не должны повторить попытку:

  • 500 Внутренняя ошибка сервера - нет RETRY, в большинстве случаев это не обнаруженные ошибки приложения, поэтому не следует повторять ее
  • 501 Не реализовано - нет RETRY
  • 502 Bad Gateway - RETRY
  • 503 Служба недоступна - RETRY
  • 504 Время ожидания шлюза RETRY
  • 505 Версия HTTP не поддерживается - нет RETRY
  • 506 Вариант также согласовывает - нет RETRY
  • 507 Недостаточно памяти - нет RETRY
  • 508 L oop Обнаружено - нет RETRY
  • 510 не расширен - нет RETRY
  • 511 Требуется сетевая аутентификация - нет RETRY

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...