proxy_cache_purge

Igor A. Ippolitov iippolitov на nginx.com
Вт Июл 31 11:54:50 UTC 2018


On 31.07.2018 00:24, jd на jdwuzhere.ru wrote:
>
>> On 30 Jul 2018, at 19:59, Igor A. Ippolitov <iippolitov на 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