Может Лакировать игнорируют хит для передачи, когда бэкенды больны
Существует ли способ иметь Лак 4, игнорируют какие-либо объекты хита для передачи в кэше, если все бэкенды были отмечены как "больные"?
Вот сценарий отказа, который я пытаюсь улучшить:
- В первых бэкендах все здоровы и ведут себя приятно, возвращая допустимое содержание с состоянием 200. Лак кэширует эти страницы и служит им согласно их TTL.
- Что-то повреждается, скажите, что запрос базы данных начинает занимать больше времени чем обычно. Бэкенды начинают возвращать страницы медленно. Затем в конечном счете запросы начинают испытывать таймаут в целом, и бэкенды начинают возвращать "Внутреннюю Ошибку Сервера" (состояние 500).
- Varnish видит эти ответы и отмечает их как хит для передачи с TTL 120 с, согласно значению по умолчанию
vcl_backend_response. - Наконец проверки состояния умирают, и Лак в конечном счете отмечает все больные бэкенды.
- Теперь когда больше запросов входит, Varnish видит объект хита для передачи в кэше и решает, что он должен сделать выборку бэкенда. Кроме всех бэкендов больны, так, чтобы результаты в 503 "Отказавших выборках бэкенда".
Эти 503 ответа продолжаются в течение максимум 2 минут, в зависимости от синхронизации первого некэшируемого ответа (отмеченный как хит для передачи) и когда бэкенды все отмечены больные. - После того, как объекты хита для передачи истекли от кэша (120 с), Лак начинает рассматривать те запросы как регулярные хиты снова и подает кэшируемые страницы с 200 состояниями в льготном режиме (согласно значению по умолчанию
vcl_hit-- "if (obj.ttl + obj.grace > 0) ....)
Одно обходное решение, которое я придумал, должно сократить TTL объектов хита для передачи, если бы они произошли из состояния 500 ответов:
sub vcl_backend_response {
if (beresp.ttl <= 0s && beresp.status == 500) {
set beresp.ttl = 10s;
set beresp.uncacheable = true;
# return inside this if statement to allow builtin vcl_backend_response to run
return (deliver);
}
}
Другие возможности корректируют интервал и порог проверок состояния, или придумывают лучшую проверку состояния.
Но кроме этого, там способ явно сказать Лак "да, у Вас есть хит для передачи, но взгляд - все бэкенды больны! Не беспокойтесь, переключайтесь на льготный режим теперь".
Если вы хотите такое поведение, вам следует избегать создания объектов «попадание-пропуск», когда вы получаете 500 ответов от бэкэнда .
Предположим, что (1) вы всегда запрашиваете один и тот же кешируемый URL / объект X; и (2) объект X в настоящее время хранится в хранилище Varnish с TTL 1 час и периодом отсрочки 24 часа. Предположим теперь следующую временную шкалу:
- t = 0: какой-то клиент запрашивает X у Varnish. Объект уже кэширован и свежий, поэтому Varnish возвращает его клиенту. Нет запросов к бэкэнду.
- t = 1: бэкэнд выходит из строя и с этого момента отвечает 500 на все запросы.
- t = 3601: некоторые клиенты запрашивают X в Varnish. Объект кэшируется, но останавливается, поэтому Varnish возвращает его клиенту и запускает фоновый запрос серверной части для обновления кэшированного объекта X.
- t = 3602: фоновый запрос базы данных получает ответ 500. Объект "попадание за проход" сохраняется с TTL 120 с. Этот объект перезаписывает остановленный объект X.
- t = 3603: некоторый клиент запрашивает X у Varnish. Обнаружен объект «хит за прохождение», и выполняется внутренний запрос. На сторону клиента отправляется ответ 500.
- t = 4000: некоторый клиент запрашивает X в Varnish. Объект X больше не находится в кеше, и некоторое время назад серверная часть была отмечена как больная. На клиентскую сторону будет отправлен ответ 503: Varnish не может связаться с серверной частью (он помечен как больной), а Varnish не может вернуть льготный контент (он был перезаписан объектом «Hit-for-Pass» на t = 3602).
Решением здесь было бы избегать создания объектов «хит за прохождение», когда вы получаете 500 ответов от бэкэнда. Вместо этого просто откажитесь от запроса. Таким образом, на t = 3603 и t = 4000 вы отправите остановленную копию объекта на клиентскую сторону.