ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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-ов
с  каждым  бэкендом  в  отдельности.  И сразу появляется лаконичность:
попробовали эту группу серверов, если там нету, то пробуем эту.

-- 
С уважением,
 Михаил                          mailto:postmaster@xxxxxxxxxxxxx

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.