Просто как вариант решения...
Отдельный модуль для nginx для remote clearing cache
С форматом вызова вроде ;
Который бы убирал все закешированые файлы URL которых попадает под
переданный regexp.
Тогда и можно не ограничивать backend/frontend одной машиной
Тогда автор backend может реализовать любой алгоритм сброса cache какой ему
необходимо (если URL навигация нормально структурирована).
> -----Original Message-----
> From: Sysoev Igor
> Sent: Tuesday, March 15, 2005 6:33 PM
> To: nginx-ru@xxxxxxxxx
> Subject: Re: Пожелание по mod_rewrite
>
>
> On Tue, 15 Mar 2005, Andrew Velikoredchanin wrote:
>
> > Boguk Maxim пишет:
> >> Генератор статического HTML и кеширование с возможностью сб
> роса отдельных
> >> документов по инициативе backend почти одно и тоже.
> >> При этом кеширование не генерирует заведомо не используемые
> страницы в
> >> отличии от генераторов статического html.
> >> В общем реально надо механизм сброса части кеша по regexp п
> о инициативе
> >> backend вот.
> >> (полный сброс не предлагать при обьеме кеша 10Gb+ :))
> >> Мне бы тоже пригодилось.
> >
> > Ну, скажем, не со стороны бэкэнда, а со стороны вообще. :) К
> ак вариант -
> > введение условий либо в механизм кэша, либо в mod_rewrite.
> >
> > Кстати, Игорь. Если делать механизм условного кэширования на
> основе времени
> > спец. файла и времени кэша текущего файла, то надо учитывать
> что путь к спец.
> > файлу должен строиться на основе url. Только вот без regexp
> думаю, здесь не
> > обойтись. Т.к. при необходимости введения спец. файла для ка
> талогов нужно
> > иметь возможность указывать не весь url, а с учетом уровня в
> ложенности.
>
> Файлы ограничивают использование одной машиной. regex'ы использовать
> нереально. Я вижу такое решение: нужно добавлять в заголовок о
> твета ключ(и),
> от которого зависит кэширование. Запросы, после которых часть ответов
> становятся неверными (например, POST'ы), должны передавать так
> ой же ключ.
> Эти ключи будут храниться в своём кеше.
>
>
> Игорь Сысоев
>
>
