Очистка и запрет

Очистка по HTTP

Очистка — это то, что происходит, когда вы выбираете объект из кэша и удаляете его вместе с его вариантами. Обычно очистка вызывается через HTTP с методом PURGE.

Очистка по HTTP похожа на запрос HTTP GET, за исключением того, что метод равен PURGE. На самом деле вы можете назвать метод как угодно, но большинство людей называют это очисткой. Например, Squid поддерживает тот же механизм. Чтобы поддерживать очистку в Varnish, вам нужно иметь следующую VCL:

acl purge {
        "localhost";
        "192.168.55.0"/24;
}

sub vcl_recv {
        # allow PURGE from localhost and 192.168.55...

        if (req.method == "PURGE") {
                if (!client.ip ~ purge) {
                        return(synth(405,"Not allowed."));
                }
                return (purge);
        }
}

Как видите, мы использовали новое действие — return(purge). Это завершает выполнение vcl_recv и переходит к vcl_hash. Это как мы обрабатываем обычный запрос. Когда vcl_hash вызывает return(lookup), Varnish очистит объект и затем вызовет vcl_purge. Здесь у вас есть возможность добавить любые необходимые действия, которые вы хотите выполнить в Varnish после очистки объекта.

Например, чтобы аннулировать главную страницу example.com, они могут обратиться к Varnish следующим образом:

PURGE / HTTP/1.0
Host: example.com

В результате Varnish удалит главную страницу. Это удалит все варианты, определенные в Vary.

Запреты

Существует еще один способ аннулирования контента: запреты. Вы можете рассматривать запреты как своего рода фильтр для объектов, уже находящихся в кэше. Вы можете ban определенный контент от отображения из вашего кэша. Вы можете запретить контент на основе любого метаданных, которые у нас есть. Запрет будет работать только с объектами, которые уже находятся в кэше, он не препятствует поступлению нового контента в кэш или его отображению.

Поддержка запретов интегрирована в Varnish и доступна в интерфейсе командной строки. Чтобы запретить все объекты PNG, принадлежащие example.com, выполните следующую команду из командной строки:

varnishadm ban req.http.host == example.com '&&' req.url '~' '\\.png$'

Подробную информацию о синтаксисе выражений запрета см. в BOOL ban(STRING). В частности, обратите внимание, что в приведенном выше примере кавычки необходимы для выполнения из командной строки, а экранирование обратной косой черты в регулярном выражении необходимо для интерфейса командной строки Varnish.

Запреты проверяются при обращении к объекту в кэше, но перед его предоставлением. Объект проверяется только на наличие более новых запретов.

Запреты, которые соответствуют только obj.*, также обрабатываются фоновыми рабочими потоками, называемыми ban lurker. ban lurker будет перебирать кучу и пытаться сопоставить объекты, а затем удалить соответствующие объекты. Насколько агрессивен ban lurker может быть настроен с помощью параметра «ban_lurker_sleep». ban lurker может быть отключен, установив «ban_lurker_sleep» в 0.

Запреты, которые старше старейших объектов в кэше, отбрасываются без оценки. Если у вас много объектов с длительным TTL, к которым редко обращаются, вы можете накопить много запретов. Это может повлиять на использование процессора и, следовательно, на производительность.

Вы также можете добавить запреты в Varnish через HTTP. Для этого потребуется немного VCL:

import std;

sub vcl_recv {
        if (req.method == "BAN") {
                # Same ACL check as above:
                if (!client.ip ~ purge) {
                        return(synth(403, "Not allowed."));
                }
                if (std.ban("req.http.host == " + req.http.host +
                    " && req.url == " + req.url)) {
                        return(synth(200, "Ban added"));
                } else {
                        # return ban error in 400 response
                        return(synth(400, std.ban_error()));
                }
        }
}

Эта строка VCL позволяет Varnish обрабатывать метод HTTP BAN, добавляя запрет на URL, включая часть хоста.

ban lurker может помочь вам поддерживать список запретов в управляемом размере, поэтому мы рекомендуем избегать использования req.* в ваших запретах, так как объект запроса недоступен в потоке ban lurker.

Вы можете использовать следующую шаблон для написания ban lurker дружественных запретов:

import std;

sub vcl_backend_response {
        set beresp.http.url = bereq.url;
}

sub vcl_deliver {
        unset resp.http.url; # Optional
}

sub vcl_recv {
        if (req.method == "BAN") {
                # Same ACL check as above:
                if (!client.ip ~ purge) {
                        return(synth(403, "Not allowed."));
                }
                # Assumes req.url is a regex. This might be a bit too simple
                if (std.ban("obj.http.url ~ " + req.url)) {
                        return(synth(200, "Ban added"));
                } else {
                        # return ban error in 400 response
                        return(synth(400, std.ban_error()));
                }
        }
}

Чтобы просмотреть текущий список запретов, выполните команду ban.list в командной строке. Это выведет статус всех текущих запретов:

0xb75096d0 1318329475.377475    10      obj.http.url ~ test
0xb7509610 1318329470.785875    20G     obj.http.url ~ test

Список запретов содержит ID запрета, метку времени, когда запрет вошел в список запретов. Количество объектов, достигших этой точки в списке запретов, необязательно с постфиксом «G» для «Gone», если запрет больше недействителен. Наконец, указано выражение запрета. Обратите внимание, что длительности не обязательно выражаются в исходной единице измерения, например, 7d преобразуется в 1w.

Запрет может быть помечен как «Gone», если это дублирующий запрет, но он по-прежнему хранится в списке для целей оптимизации.

Принудительное отсутствие кеширования

Последний способ аннулирования объекта — метод, который позволяет вам обновить объект, принудительно вызывая hash miss для одного запроса. Если вы установите «req.hash_always_miss» в значение true, Varnish пропустит текущий объект в кэше, тем самым заставив выполнить запрос к бэкенду. В свою очередь, это позволит добавить свежеполученный объект в кэш, тем самым заменив текущий. Старый объект останется в кэше до истечения ttl или его удаления другими способами.