Мне нужно сделать недействительным кеш набора URL-адресов, связанных с ресурсом, который был удален / неопубликован или обновлен. Например, если UUID моего ресурса 1234abcd Я хочу сделать недействительными все его кешированные производные под /resource/1234abcd/*.
Я понимаю, что в Varnish нет возможности сделать это с purge, но это можно сделать с помощью банов. Однако мне сложно понять, как именно работают баны.
Если, например, Я обновляю ресурс 1234abcd и запретить все его производные, я предполагаю, что следующий запрос клиента на /resource/1234abcd/derv1 будет новой серверной выборкой, и этот новый ресурс будет кэширован. Будут ли у меня две версии одного и того же производного инструмента, одна запрещенная, а другая нет (пока не истечет срок действия старой версии и не истечет ее бан)? Если у моих ресурсов длинный срок годности, я могу накопить много запретов на ресурсы кеша, которые я бы предпочел немедленно очистить.
На уровне разработки программного обеспечения, в чем польза оставлять недоступные ресурсы, вместо реализации очистки на основе регулярных выражений, которая кажется более простой в управлении?
Кроме того, я реализовал запрет в своей среде разработки и вижу, что запрет вступает в силу только через минуту или около того после запроса. Связано ли это со скрытым баном или другими настройками времени?
Спасибо.
Баны в Varnish устанавливаются на основе так называемого список запретов. Элементы в списке запрета соответствуют определенным критериям, которые идеально соответствуют свойствам кэшированного объекта.
В запретить скрытеньких, отдельный поток, отслеживающий список запретов, отвечает за удаление соответствующих объектов.
В большинстве случаев вам нужно сопоставить шаблон URL, который необходимо сделать недействительным.
Легче всего было бы наложить следующий бан:
req.http.host == example.com && req.url ~ /resource/1234abcd/.*
Проблема с этим примером заключается в объем запроса: скрытый бан имеет доступ только к объекту и его свойствам. Информация запроса не является частью этого, потому что объект содержит только информацию ответа.
В этом случае скрытый объект не найдет элемент в списке запретов, и этот элемент останется в кеше до тех пор, пока следующий пользователь не найдет соответствующий URL-адрес. Это неэффективно.
Чтобы обойти эти ограничения области видимости, мы используем уловку, добавляя хозяин & url информация к ответу.
Вот как это сделать:
sub vcl_backend_response {
set beresp.http.url = bereq.url;
set beresp.http.host = bereq.http.host;
}
sub vcl_deliver {
unset resp.http.url;
unset resp.http.host;
}
Затем вы можете запустить следующий бан:
obj.http.host == example.com && obj.http.url ~ /resource/1234abcd/.*
Скрытень сможет сопоставить эти свойства и удалит соответствующие объекты из кеша без необходимости выполнения запроса.
В varnishd В двоичном файле есть пара настроек времени выполнения, которые влияют на то, как бан скрывается от банов:
Есть 3 способа заблокировать:
varnishadm двоичный локальноВот varnishadm пример:
varnishadm ban obj.http.host == example.com '&&' obj.http.url '~' '\\.png$'
Для получения дополнительной информации о пульте CLI Звоните, посмотрите: http://varnish-cache.org/docs/6.0/reference/varnish-cli.html#varnish-command-line-interface
Вот HTTP пример:
acl purge {
"localhost";
"192.168.55.0"/24;
}
sub vcl_recv {
if (req.method == "PURGE") {
if (!client.ip ~ purge) {
return(synth(405,"Not allowed."));
}
if(req.http.x-purge-regex) {
ban("obj.http.host == " + req.http.host +" && obj.http.url ~ " + req.http.x-purge-regex);
return(synth(200, "Purged."));
}
return (purge);
}
}
В этом HTTP Например, мы объединяем очистка и запрет.
Обычный чистка выдан завиток будет выглядеть так:
curl -XPURGE http://example.com/resource/1234abcd/abc
Более гибкий очистка регулярных выражений с помощью запреты, будет выглядеть так:
curl -XPURGE -H"x-purge-regex: /resource/1234abcd/.*" http://example.com
Запрет не без проблем.
Вся концепция запретов основана на сопоставлении шаблонов в списке с объектами, хранящимися в кеше.
Такие большие списки запретов и множество объектов могут вызвать большие накладные расходы процессора
Еще один вариант использования банов: аннулирование на основе тегов.
Иногда довольно сложно преобразовать изменение объекта в совпадающие URL-адреса. Иногда вы даже не знаете, на какие URL-адреса влияет изменение объекта.
В этом случае имеет смысл пометить контент и сделать недействительными объекты, соответствующие одному из этих тегов.
В своем приложении вы должны выдавать такие заголовки ответов:
X-Cache-Tags: type:resource, id:1234abcd, category:product
Если вы затем хотите удалить все ресурсы, которые являются частью товар категории, вы можете просто ввести следующий бан:
ban obj.http.x-cache-tags ~ category:product
Если вы планируете использовать запреты для аннулирование на основе тегов, вы столкнетесь с теми же проблемами с процессором, если ваш список запретов быстро растет и у вас слишком много объектов в кеше, которые необходимо проверить.
Лучшее решение - использование xkey, который представляет собой модуль Varnish, поставляемый с Коллекция модулей лака. Видеть https://github.com/varnish/varnish-modules/blob/master/src/vmod_xkey.vcc для получения дополнительной информации.
Вы должны скомпилировать этот модуль, но API более гибкий, а производительность намного лучше.