Звучит как-то необычно, есть пример рабочего конфига? хотя бы этого самого специального локейшна?… что-то не придумывается конфиг который позволит внутри nginx принудительно обновить элемент в кеше
> On 31 Jul 2018, at 13:54, Igor A. Ippolitov <iippoli...@nginx.com> wrote: > > On 31.07.2018 00:24, j...@jdwuzhere.ru <mailto:j...@jdwuzhere.ru> wrote: >> >>> On 30 Jul 2018, at 19:59, Igor A. Ippolitov <iippoli...@nginx.com> wrote: >>> >>>> On 30.07.2018 14:29, Gena Makhomed wrote: >>>>> On 30.07.2018 14:06, Igor A. Ippolitov wrote: >>>>> >>>>> Мне кажется, что proxy_cache_bypass легко позволяет замещать контент в >>>>> кэше (что и делает purge, в широком смысле). >>>> Замещать существующий контент или добавлять новый - да. >>>> Но удалять не позволяет, в этом и состоит (небольшое) отличие. >>> Но ведь какой-то ответ на запрос "пурженного" контента всё равно придёт >>> клиенту? Почему бы не закэшить сразу его. >>> Или условную болванку с max-age:0, которая будет обновлена по первому же >>> запросу от клиента >> Погодите, я что-то потерялся. Есть профиль игрока, который не меняется >> неделями. Nginx всю неделю (TTL кэша) радостно отдаёт страницу профиля из >> этого кэша. Но однажды, игрок начинает играть в новое и профиль необходимо >> обновить. Как без purge сообщить nginx, что информация обновилась и надо >> сходить в backend за новой страницей, чтобы положить её в кэш до следующего >> прихода? > Как бы вы делали PURGE для профиля игрока? URL профиля вы знаете. > > Для PURGE вы бы "дёрнули" запрос, который удалит ненужный элемент и в > следующий раз nginx перезапросит контент с апстрима. > Этот запрос, обычно, приходит в отдельный location с нужными настройками: > ключ кэша, права доступа, всякое такое. > > В моём подходе вы "дёргаете" такой же запрос в специальный location, который > ходит в апстрим мимо кэша (proxy_cache_bypass). > В разных вариациях, апстримом будет: > либо сам nginx, который отдаёт HTTP 200 и Cache-Control: max-age=0; > либо реальный апстрим, который отдаст актуальную копию данных > > В первом случае контент сразу "протухает" и его актуализируют на первом же > запросе. > Во-втором - сразу актуальный. > > В следущий раз, когда запросят профиль пользователя, nginx либо пойдёт в > апстрим, либо отдаст актуальную кэшированную версию. > >> >>> На первый взгляд, PURGE не кажется необходимым средством. Хотя, вероятно. >>> может упростить жизнь в каких-то конфигурациях. >>>> Вот поэтому и не понятно, почему нельзя сделать директиву >>>> proxy_cache_purge доступной в open source версии nginx? >>>> >>>> Могу ошибаться, но коммерческую версию nginx покупают скорее всего >>>> не из-за директивы proxy_cache_purge, а ради других возможностей. >>>> >>>>>>> Если не прояснится - попробовать воспроизвести как минимум без >>>>>>> "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди >>>>>>> отваживаются использовать эту поделку, она при любых внутренних >>>>>>> изменениях в nginx'е разносит всё же) >>>>>> Если не использовать этот кривой сторонний модуль ngx_cache_purge, >>>>>> то какие у пользователей open source версии nginx есть альтернативы? >>>>>> Директиву proxy_cache_purge >>>>>> можете сделать доступной в open source версии nginx? >>>> P.S. >>>> >>>> Please do not top-post. >>>> >>>> Answer: Because it turns the discussion up-side-down. >>>> >>>> Question: Why should I not top-post? >>>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > nginx-ru mailing list > nginx-ru@nginx.org <mailto:nginx-ru@nginx.org> > http://mailman.nginx.org/mailman/listinfo/nginx-ru > <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
