<div dir="ltr">Тема, конечно, старая, и уже "завяла", но:<div><br><div>а как Вы собираетесь инвалидировать кэш если у вас, к примеру, стоит 2 frontend'а и каждый из них кэширует независимо?</div><div>Вот пришёл, к примеру, один юзер на FE1,  страница закэшировалась. Второй - на FE02, страница закэшировалась ещё раз. Потом прошёл какой-то запрос, в ответе на который была инвалидация по заданному ключу. И этот запрос проксируется ведь только одиним FE (например, первым). В итоге, второй FE будет отдавать старые данные и схема будет неработоспособной (если, конечно, не допускать, что при обновлении страницы пользователь может получать разные данные).</div>
<div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">26 июля 2013 г., 21:01 пользователь Dmitry E. Oboukhov <span dir="ltr"><<a href="mailto:unera@uvw.ru" target="_blank">unera@uvw.ru</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">>> нет это совсем не то что в фичареквесте.<br>
>><br>
> ...<br>
>><br>
>> я хочу получить механизм внутри обработчика сбросить кеш на другом<br>
>> роуте.<br>
>> как вариант - выдать хидер с урлом кеш на котором надо сбросить.<br>
>><br>
>> а директивы в конфиге = это не программа это набор условий :)<br>
>><br>
> я раньше решал похожую проблему с помощью модуля ngx_cache_purge (<br>
> <a href="http://wiki.nginx.org/CachePurgeChs" target="_blank">http://wiki.nginx.org/CachePurgeChs</a> ). создавал в nginx специальный<br>
> локейшн (/purge/), при обращении к которому удалялся из кеша указанный<br>
> элемент. Т.е. после изменения в базе, запрос по этому локейшну делает<br>
> само приложение (для wordpress есть специальный плагин). Подробнее (с<br>
> конфигами) можно почитать тут:<br>
<br>
> <a href="http://mailman.nginx.org/pipermail/nginx-ru/2013-February/050061.html" target="_blank">http://mailman.nginx.org/pipermail/nginx-ru/2013-February/050061.html</a><br>
> <a href="http://mailman.nginx.org/pipermail/nginx-ru/2012-December/049347.html" target="_blank">http://mailman.nginx.org/pipermail/nginx-ru/2012-December/049347.html</a><br>
<br>
> но теперь, я бы попытался реализовать соответствующий функционал без<br>
> стороннего модуля, а только директивой proxy_cache_bypass.<br>
<br>
</div>proxy_cache_bypass ведь не дает того функционала о котором я говорю:<br>
когда один роут сбрасывает кеш на другом роуте.<br>
<div class="im"><br>
> Таким образом, применяя предложенную мной схему, вместо того чтобы<br>
> просто отдать nginx страницу с заголовком X-Cache-Invalid:<br>
> "/users/top/123?all=yes", вам придётся сначала сделать запрос из<br>
> приложения по адресу /purge/users/top/123?all=yes и элемент кеша<br>
> обновится.<br>
<br>
</div>я посмотрю внутрь модуля. сложно его доработать до того функционала<br>
что я говорю?<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
<br>
. ''`.                               Dmitry E. Oboukhov<br>
: :’  :   email: <a href="mailto:unera@debian.org">unera@debian.org</a> jabber://<a href="mailto:UNera@uvw.ru">UNera@uvw.ru</a><br>
`. `~’              GPGKey: 1024D / F8E26537 2006-11-21<br>
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537<br>
</div></div><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<br>
iEYEAREDAAYFAlHyq1wACgkQq4wAz/jiZTe0JwCePKuBoExhqU/EEzIzqC8xFBpm<br>
MhQAoNBbH8GwYwoba7m0bAd9mZhX41yl<br>
=ArMD<br>
-----END PGP SIGNATURE-----<br>
<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><br></blockquote></div><br></div>