Re[2]: Интелектуальный try_files по сети

[Михаил Монашёв]

Здравствуйте, Maxim.

>> >> Было  бы  удобно  иметь  возможность  прописывать вот такую логику:
>> >> поискать  файл на этих бэкендах, а если там не нашлось, то на этих.
>> >> Это  удобно в стандартной задаче, когда хочется показать только что
>> >> загруженную  фотку.  Форму  удобно  постить  на  сервер  с апачами,
>> >> картинку  раздавать  с  кэширующего  сервера, а хранить картинку на
>> >> сервере  с  файловым  архивом.  Т.е.  сначала  картика  кладётся на
>> >> апаческий  хост,  а  потом  в  фоне  копируется  на хост с файловым
>> >> архивом.
>> >> 
>> >> Сейчас  подобную  схему  можно сделать двумя способами: редиректить
>> >> юзеров,  чтобы  браузер  сам  обходил  все  возможные  сервера, или
>> >> городить на кэширующем сервере кучу if-ов.
>> 
>> > А  чем  тебе старый добрый вариант с "error_page 404 = @fallback" не
>> > угодил?
>> 
>> > Собственно,  от  try_files его по большому счёту отличает только то,
>> > что  try_files  писать чуть проще для разных типичных случаев. (Ну и
>> > тем,  что в отличие от try_files там нет race condition при проверке
>> > и  отдаче  файлов, но это тема, интересная только отдельным маньякам
>> > вроде меня.)
>> 
>> Под  кучей  if-ов и имел ввиду твой старый добрый вариант. Неправильно
>> выразился,  прошу  прощения. Просто хотел заметить, что когда бэкендов
>> десяток,  то  конфиг  не блещет изяществом и похож на копипасту. Кроме
>> того такая конструкция не позволяет всякие оптимизации типа выполнения
>> сразу  10  запросов  параллельно  вместо последовательного перебора. И
>> кажется, что работа с бэкендами - это ближе к апстриму.

> Исходная задача "посмотреть файл на этих бекендах, а если не 
> нашлось, то на этих" - не параллелится.

Параллелится "посмотреть файл на этих бекендах" и "то на этих".

>> Ещё   придумал   третий  вариан  решения.  Задача  сейчас  симпатичнее
>> решается,   если  отделить  статусы,  вызывающие  fail,  от  статусов,
>> приводящих к выбору следующего бэкенда. Что-то вроде:
>> 
>> proxy_next_upstream [error | timeout | invalid_header |
>> http_500 | http_502 | http_503 | http_504 | http_404[=not_fail] |
>> off]
>> 
>> Тогда  в @fallback можно писать сразу апстрим вместо кучи @fallback-ов
>> с  каждым  бэкендом  в  отдельности.  И сразу появляется лаконичность:
>> попробовали эту группу серверов, если там нету, то пробуем эту.

> Сейчас так и есть.  Если тебе нужно в рамках группы бекендов 
> поискать файл, то

>     proxy_next_upstream http_404;

> эту проблему решает (и не объявляет бекенд мёртвым, если он 
> возвращает 404, а просто переходит к следующему бекенду).

Сорри, торможу.

-- 
С уважением,
 Михаил                          mailto:postmaster at softsearch.ru