Кеширование
Кэширование, капстоун: тест с выбором ответа
Суть Тест с выбором на синтез по всему треку кэширования — владение уровнями, каскад TTL, защита от stampede и dogpile, валидаторы, SWR и распространение инвалидации как единая стратегия.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего трека. Ни один не проверяет отдельную директиву в изоляции — каждый требует рассуждать о том, как компонуются два или больше уровня, а именно там и живут реальные баги кэширования.
Цель
Убедись, что связываешь владение уровнями, каскад TTL, защиту от stampede, валидаторы и stale-while-revalidate в единую связную стратегию — тот синтез, к которому вели отдельные юниты.
Викторина
Completed
Запрос проходит через CDN, reverse proxy, Redis и БД. Редактор меняет товар, write-path обновляет БД и удаляет ключ Redis, но пользователи час видят старую цену. Где баг?
Heads-up Удалённый ключ Redis вызывает промах, который пересчитывает из БД — свежее значение. Пользователь, прикованный к старой цене на час, указывает на внешний кэш (CDN), держащий копию, которую никто не инвалидировал, а не на Redis.
Heads-up Query/buffer-кэш БД инвалидируется автоматически той записью, что изменила строку. Устаревшая копия выживает на уровне, не связанном с write-path — на CDN.
Heads-up Несовпадающие TTL не дают ошибки; они молча отдают устаревшее. Более длинный внешний TTL побеждает для пользователя, пока не истечёт или его явно не purge'нут.
Викторина
Completed
Ты ставишь CDN s-maxage=3600, но приложение ревалидирует свой фрагмент в Redis каждые 60с. Почему это баг композиции, независимо от того, какие числа корректны по отдельности?
Heads-up Redis не источник истины, и даже если бы был, внутреннее обновление невидимо внешнему кэшу. CDN отдаёт свою копию все 3600с независимо от Redis.
Heads-up s-maxage — это именно директива, которую соблюдают разделяемые кэши вроде CDN; max-age нацелен на приватный кэш браузера. CDN соблюдает 3600с.
Heads-up Равное сокращение оставляет внешнее окно больше-или-равным внутреннему, поэтому тот же зазор отдачи устаревшего сохраняется. Дефект в порядке (внешнее должно быть ≤ внутреннего), а не в абсолютном размере.
Викторина
Completed
Горячий ключ с тысячами параллельных читателей истёк. Можно добавить (a) per-key mutex, чтобы один запрос пересчитывал, пока остальные ждут, или (b) stale-while-revalidate. Сениор обычно сначала берёт SWR. Почему?
Heads-up Ограниченный per-key lock с таймаутом не даёт deadlock; single-flight — корректная защита от stampede. Причина предпочесть SWR — задержка, а не безопасность: mutex заставляет ожидающих блокироваться, SWR — нет.
Heads-up Наоборот: весь механизм SWR — отдавать устаревшую копию, пока он ревалидирует. Его выбирают, когда ограниченная устарелость приемлема; mutex прав, когда читатели должны увидеть пересчитанное значение.
Heads-up Mutex (single-flight) — это именно механизм защиты origin: он схлопывает N промахов в один пересчёт. Оба защищают origin; различаются в том, блокируются ли ожидающие.
Викторина
Completed
Публичное API-чтение стоит 40мс на вычисление и меняется редко. Нужны низкая задержка, низкая нагрузка на origin и экономия трафика на проводе. Какая комбинация компонует это правильно?
Heads-up Один max-age не даёт мягкого истечения (нет SWR, поэтому первый читатель после истечения съедает 40мс) и дешёвой ревалидации (нет ETag, поэтому каждая ревалидация шлёт полное тело). Он решает одну стоимость и игнорирует две.
Heads-up no-store запрещает edge и браузеру кэшировать, выбрасывая самые дешёвые выигрыши (zero-RTT попадания в браузере, разгрузка edge, 304). Один серверный кэш оставляет каждого клиента платить полный RTT и трафик.
Heads-up ETag всё равно требует round-trip на запрос, чтобы получить 304; без s-maxage нет локального попадания, а без SWR ревалидация синхронна. ETag экономит трафик, а не round-trip и не обрыв задержки.
Викторина
Completed
Залогиненный дашборд рендерит персональные платёжные данные и стоит за разделяемым CDN. Хэндлер возвращает 200 без Cache-Control. В чём реальный риск и правильное исправление?
Heads-up Именно это допущение о прямой доставке клиенту может молча отменить изменение конфигурации edge, proxy или правило surrogate-key. Это класс утечки Steam 2015: неаннотированный аутентифицированный 200 сохранён и отдан чужому.
Heads-up Vary: Cookie ключуется на весь cookie, обрушивая hit-rate почти до нуля и рискуя коллизиями при одной пропущенной нормализации. Для персональных данных ответ — private/no-store, а не хрупкий Vary.
Heads-up Короткий TTL не делает персональный контент безопасным в разделяемом кэше — всё окно CDN отдаёт платёжную страницу одного пользователя другим. TTL управляет устарелостью, а не аудиторией.
Викторина
Completed
Поперёк всего стека: какое утверждение о fail open во время сбоя origin верно?
Heads-up SWR срабатывает на истечение и ревалидирует против здорового origin; если origin лежит, фоновая ревалидация падает. stale-if-error — это директива, которая специально покрывает случай ошибки и недоступности.
Heads-up Некоторые данные небезопасны устаревшими — флаг наличия на складе, отданный устаревшим, может привести к oversell. Сениорское решение по-ресурсное: длинно для прайс-листа, коротко или нулём для критичного к корректности состояния.
Heads-up Любой уровень кэширования может fail open — reverse proxy с stale-if-error, application-кэш, настроенный отдавать последнее значение при ошибке origin. Это свойство композиции всего стека.
Итог
Сквозная линия трека — единая скомпонованная стратегия: назначь каждому уровню данные, которыми он владеет, сокращай окна свежести наружу (или purge’ай внешний уровень на каждое внутреннее изменение), защищай origin на истечении горячего ключа через single-flight или SWR, экономь трафик через 304 на ETag, ограничивай персональные ответы через private/no-store, встраивай инвалидацию в write-path, чтобы она распространялась Redis → proxy → CDN по порядку, и fail open через stale-if-error, настроенный по-ресурсно. Ответ не в одной директиве; ответ в том, как уровни компонуются.