gridfs решит проблему.<br><br><div class="gmail_quote">14 декабря 2011 г. 15:31 пользователь Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hello!<br>
<div><div class="h5"><br>
On Wed, Dec 14, 2011 at 01:35:15AM +0400, Михаил Монашёв wrote:<br>
<br>
> Здравствуйте, Maxim.<br>
><br>
> >> Было  бы  удобно  иметь  возможность  прописывать вот такую логику:<br>
> >> поискать  файл на этих бэкендах, а если там не нашлось, то на этих.<br>
> >> Это  удобно в стандартной задаче, когда хочется показать только что<br>
> >> загруженную  фотку.  Форму  удобно  постить  на  сервер  с апачами,<br>
> >> картинку  раздавать  с  кэширующего  сервера, а хранить картинку на<br>
> >> сервере  с  файловым  архивом.  Т.е.  сначала  картика  кладётся на<br>
> >> апаческий  хост,  а  потом  в  фоне  копируется  на хост с файловым<br>
> >> архивом.<br>
> >><br>
> >> Сейчас  подобную  схему  можно сделать двумя способами: редиректить<br>
> >> юзеров,  чтобы  браузер  сам  обходил  все  возможные  сервера, или<br>
> >> городить на кэширующем сервере кучу if-ов.<br>
><br>
> > А  чем  тебе старый добрый вариант с "error_page 404 = @fallback" не<br>
> > угодил?<br>
><br>
> > Собственно,  от  try_files его по большому счёту отличает только то,<br>
> > что  try_files  писать чуть проще для разных типичных случаев. (Ну и<br>
> > тем,  что в отличие от try_files там нет race condition при проверке<br>
> > и  отдаче  файлов, но это тема, интересная только отдельным маньякам<br>
> > вроде меня.)<br>
><br>
> Под  кучей  if-ов и имел ввиду твой старый добрый вариант. Неправильно<br>
> выразился,  прошу  прощения. Просто хотел заметить, что когда бэкендов<br>
> десяток,  то  конфиг  не блещет изяществом и похож на копипасту. Кроме<br>
> того такая конструкция не позволяет всякие оптимизации типа выполнения<br>
> сразу  10  запросов  параллельно  вместо последовательного перебора. И<br>
> кажется, что работа с бэкендами - это ближе к апстриму.<br>
<br>
</div></div>Исходная задача "посмотреть файл на этих бекендах, а если не<br>
нашлось, то на этих" - не параллелится.<br>
<div class="im"><br>
> Ещё   придумал   третий  вариан  решения.  Задача  сейчас  симпатичнее<br>
> решается,   если  отделить  статусы,  вызывающие  fail,  от  статусов,<br>
> приводящих к выбору следующего бэкенда. Что-то вроде:<br>
><br>
> proxy_next_upstream [error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_404[=not_fail] | off]<br>
><br>
> Тогда  в @fallback можно писать сразу апстрим вместо кучи @fallback-ов<br>
> с  каждым  бэкендом  в  отдельности.  И сразу появляется лаконичность:<br>
> попробовали эту группу серверов, если там нету, то пробуем эту.<br>
<br>
</div>Сейчас так и есть.  Если тебе нужно в рамках группы бекендов<br>
поискать файл, то<br>
<br>
    proxy_next_upstream http_404;<br>
<br>
эту проблему решает (и не объявляет бекенд мёртвым, если он<br>
возвращает 404, а просто переходит к следующему бекенду).<br>
<span class="HOEnZb"><font color="#888888"><br>
Maxim Dounin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></div></div></blockquote></div><br>