Вопросы Теги

Запрос силы, чтобы пропустить кэш, но все еще сохранить ответ

Если необходимо записать в %windir%\system32\macromed\flash из сценария было бы намного лучше использовать компьютерный сценарий запуска.

У обычного пользователя обычно не будет доступа для записи к той папке.

Вы можете также предпочтения Групповой политики для копирования файлов на машины, если Вы только заботитесь о Windows 7?

7
задан 30 September 2013 в 15:58
2 ответа

req.hash_always_miss должно помочь.

Не выполняйте полную очистку кеша в начале запуска паука. Вместо этого просто установите работу паука - и в вашем vcl_recv установите запросы паука так, чтобы они всегда пропускали поиск в кэше; они получат новую копию из бэкэнда. 

acl spider {
  "127.0.0.1";
  /* or whereever the spider comes from */
}

sub vcl_recv {
  if (client.ip ~ spider) {
    set req.hash_always_miss = true;
  }
  /* ... and continue as normal with the rest of the config */
}

Пока это происходит и пока новый ответ не будет в кэше, клиенты будут продолжать беспрепятственно получать старый кеш, обслуживаемый им (пока он все еще находится в пределах его TTL).

10
ответ дан 2 December 2019 в 23:26

Ответ Шейна выше лучше, чем этот. Это альтернативное решение, более сложное и имеющее дополнительные проблемы. Пожалуйста, проголосуйте за ответ Шейна, а не за этот. Я просто показываю другой метод решения проблемы.

Моей первоначальной мыслью было return (pass); в vcl_recv , а затем, после получения запроса, в vcl_fetch , каким-то образом проинструктировать Varnish о том, что он должен кэшировать объект, даже если он был специально передан ранее.

Оказывается, это невозможно :

Если вы решили передать запрос в более ранней функции VCL (например: vcl_recv), вы по-прежнему будете выполнять логику vcl_fetch, но объект не войдет в кеш, даже если вы укажете время кеширования.

Итак, следующий лучший вариант - запустить поиск, как обычный запрос, но убедитесь, что он всегда терпит неудачу. Невозможно повлиять на процесс поиска, поэтому он всегда будет попадать (при условии, что он кэшируется ; если это не так, то он все равно пропустит и сохранит). Но мы можем повлиять на vcl_hit : 

sub vcl_hit {
    # is this our spider?
    if (req.http.user-agent ~ "Wget" && client.ip ~ spider) {
        # it's the spider, so purge the existing object
        set obj.ttl = 0s;
        return (restart);
    }

    return (deliver);
}

Мы не можем заставить его не использовать кеш, но мы можем очистить этот объект из кеша и перезапустить весь процесс. Теперь он возвращается к началу, в vcl_recv , где в конечном итоге выполняет еще один поиск. Поскольку мы очистили объект, который уже пытаемся обновить, он пропустит, затем получит данные и обновит кеш.

Немного сложно, но работает. Единственное окно для пользователя, застрявшего между очисткой и сохранением ответа, - это время для обработки одного запроса. Не идеально, но неплохо.

2
ответ дан 2 December 2019 в 23:26

Теги

Похожие вопросы