Это конечно оффтопик, но аналогичную задачу решил через одно место:

Так как "популярных" файлов ограниченное количество, все зеркала
смонтированы друг с другом по nfs. Кешированием занимается cachefilesd
(если надо выложу исходники 0.10 для сборки deb, так как изначально он
для RH и соответственно rpm), в ядре соответственно д.б. поддержка
fs-cache (более менее стабильно заработало с 2.6.35+). Под кеш
выделено несколько терабайт. Всё работает более менее, проблемы
начинаются только при потере связности, впрочем при её восстановлении
сами и пропадают (география узлов довольно обширная - северозапад
россии).

Буду рад услышать соображения по этому поводу. Конторы с аналогичными
задачами - давайте объединяться. Оптимальным вариантом было бы
предложение от nginx сделать "busy locks" за такие то деньги в такие
то сроки. А мы бы скинулись по возможности. К сожалению если нет
времени самому заняться (а задача то интересная и не тривиальная!) то
надо заплатить тому, кто может - а кто как не nginx (Игорь, Максим и
т.д.) это может лучше всех? :)

22 сентября 2011 г. 10:14 пользователь Danila Shtan <danila@shtan.ru> написал:
> Про тяжелые бэкенды — понятно.
>
> Но Vladimir Stavrinov говорит про трафик и место на дисках.
>
> Насколько я понял из его объяснений — у него вообще чуть ли не статика
> раздается, а nginx в режиме кэширующего прокси работает в качестве
> зеркала.
>
> Д.
>
> 2011/9/22 Daniel Podolsky <onokonem@gmail.com>:
>>> Ну и кроме того -- не слишком ли надумана проблема? Ситуация возникает
>>> исключительно в период между началом и концом первого запроса к файлу
>>> на бэкенде.
>> Вообще - busy locks требуются очень редко.
>>
>> В моей практике таких проектов было 2, но зато на одном из них до сих
>> пор трудится mod_accel - без busy locks там все умирает сразу.
>>
>> busy locks эти актуальны, если к нам клиенты ходят за одним и тем же,
>> и - волнами. Например, мы их сами провоцируем, сообщая, скажем,
>> "апдейт готов".
>> И тогда все 100,000-1,000,000 клиентов приходят к нам в течение 20 минут.
>> А бекенд тяжелый, лезет в базу на каждый запрос, и сторонний -
>> встроить кеширование прямо в него не удалось за последние 8 лет. То
>> есть - удалось бы, конечно, если бы busy locks не решили проблему.
>>
>> То есть - очень узкоспециальная задача: много клиентов, неравномерное
>> распределение трафика по времени, неравномерное распределение
>> популярности урлов, квазидинамический контент, говнобекенд.
>>
>> Вот и получается, что не "must have", а "would be nice", в лучшем случае.
>>
>> Но мне лично актуально все равно :) Так уж вышло, что говнобекенды
>> преследуют меня...
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



--
Cogito ergo sum
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru