Буфер запрашивает к nginx в течение короткого времени, если бэкенд снижается

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

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

Есть две возможности того, что происходит на восходящей стороне:

• «Навсегда» может быть принимает соединение и немедленно возвращает ошибку. В этом случае, похоже, вы действительно должны спросить, как заставить его не неправильно обрабатывать соединение, но подождите, пока ваше приложение завершит развертывание, и обработайте запрос тут же. Приложение opengrok на сервере tomcat имеет эту проблему.

• Никто не прослушивает порт, на котором должно работать ваше приложение, поэтому , ядро ​​немедленно отбрасывает пакет и сразу же возвращает пакет TCP RST.

  • Если причиной является TCP RST , вы можете решить эту проблему, если навсегда продолжит прослушивание сокета, или настроив ядро ​​для постановки входящих пакетов в очередь на определенное время, в ожидании того, что кто-то заберет их позже, так что когда навсегда действительно запустится, у него будет готовая очередь для обслуживание.

  • Настройте ядро ​​так, чтобы оно не выдавало TCP RST , когда никто не слушает, тогда ваш тайм-аут в nginx будет иметь эффект. Затем настройте nginx для отправки второго запроса другому восходящему потоку.

Если вы решите один из вышеперечисленных случаев, все готово.

В противном случае вы должны попытаться настроить nginx для исправьте проблему:

• Вы можете попробовать proxy_cache с proxy_cache_use_stale .

• Вы можете попробовать использовать обработчик ошибок: см. proxy_intercept_errors (возможно, применяется только если 503, которое вы получаете, передается из вашего бэкэнда) и error_page . Вы могли бы потратить время на обработчик ошибок, пока ваше приложение не вернется к работе, а затем сделать запрос к вашему приложению.

  • Вы можете потратить время, запустив второе приложение, которое просто выполнит sleep () сколько бы времени ни потребовалось для повторного развертывания вашего приложения, затем либо выполните перенаправление HTTP, либо завершите работу без ответа; черт возьми, вы могли бы просто реализовать это, попытавшись проксировать TCP-порт, который вы блокируете drop в брандмауэре, что активирует ваши таймауты в nginx. Затем настройте nginx для выполнения второго запроса.

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

Это возвращает нас к вашему серверу приложений: если он не может справиться с проблемой чистого повторного развертывания, тогда, возможно, вам стоит запустить два таких сервера приложений и использовать nginx для балансировки нагрузки между ними. Или разверните их заново, а затем переключите nginx на новую копию, когда она действительно будет готова. Иначе, как вы могли быть уверены, что ваши клиенты будут готовы ждать даже 30 секунд, пока ваш API не ответит?