Суть Читай реальные заголовки ответа, строку Cache-Control, обработчик edge worker и CDN-трейс, затем выбирай поведение или фикс с наибольшим рычагом.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбите
◷ 14 min
Проблемы CDN диагностируются в заголовках ответа, строках Cache-Control и логах edge — не в прозе. Прочитай каждый артефакт, предскажи, что реально делают кеш и worker, затем выбери фикс, к которому senior тянется первым.
Цель
Отработай цикл каждого инцидента CDN: читай заголовки и трейс, предсказывай кешируемость и hit rate, выбирай изменение с наибольшим рычагом до того, как трогать маршрутизацию или origin.
Hit rate на этом кешируемом HTML около 5%. Читая только эти заголовки, какова доминирующая проблема и фикс?
Heads-up Годовой TTL на изменяемом HTML неверен, и TTL не причина обвала hit rate. Cache key фрагментирован через Vary: User-Agent + Cookie — именно это убивает переиспользование.
Heads-up Единственный MISS — лишь этот один холодный запрос; ответ КЕШИРУЕМ (public, max-age). Хронический hit rate 5% — от фрагментации cache key на запрос через Vary, а не от выключенного кеша.
Heads-up age: 0 просто значит, что это свежий MISS, который заполняется. Укорачивание TTL ещё снизит hit rate. Реальная вина — Vary-заголовок высокой кардинальности.
Эндпоинт листинга товаров шлёт это. Опиши, что делает общий кеш CDN на 0-й секунде, на 120-й секунде и во время 8-минутного сбоя origin на 300-й секунде.
Heads-up 60 с — вполне валидное окно свежести общего кеша; public делает его кешируемым на CDN. SWR и SIE затем продлевают полезную отдачу далеко за него.
Heads-up Именно это и предотвращает stale-while-revalidate=600: после max-age он отдаёт stale всем и шлёт одну фоновую ревалидацию, так что стадо не доходит до origin.
Heads-up stale-if-error отдаёт stale только пока origin сбоит, в пределах своего окна; на следующей успешной ревалидации CDN кеширует свежий 200 и возобновляет нормальное поведение.
Сниппет 3 — edge worker
export default { async fetch(req, env) { const page = await fetch(req); // кешируемые chrome + body const price = await fetch(env.PRICING_URL); // на пользователя, не кешируется return new HTMLRewriter() .on("#price", { element(e) { e.setInnerContent(price.statusText); } }) .transform(page); },};
Викторина
Completed
Этот worker edge-side composition верен по форме, но имеет баг латентности на критическом пути. Какой и каков фикс?
Heads-up HTMLRewriter — потоковый парсер; в этом весь смысл. Латентность — от ожидания fetch страницы и fetch цены одного за другим вместо параллели.
Heads-up Одна перезапись innerContent — субмиллисекунда CPU, а ожидание I/O не идёт в бюджет wall-time. Дефект — сериализованный I/O, лечится распараллеливанием fetch.
Heads-up Edge workers рутинно делают fetch к внешним и региональным сервисам; это базовый кейс. Реальная проблема — два fetch последовательно на критическом пути.
Ты выкатил исправленную версию /article/42 десять минут назад, но пользователи всё ещё видят старый текст. Читая этот трейс — почему и каков самый быстрый верный фикс?
Heads-up age 7200 заметно меньше max-age 86400, поэтому запись ещё свежа и будет отдаваться ещё ~22 часа. Сейчас её снимет только purge (или истечение TTL).
Heads-up HIT — это edge-кеш CDN, не браузер, и рефреш одного пользователя не чинит никого другого. Общую edge-копию для всех инвалидирует именно CDN purge.
Heads-up Смена max-age влияет только на ответы, закешированные после изменения; уже закешированная запись держит своё исходное окно 86400 с. Чтобы снять её сейчас, нужен purge.
Итог
Каждый инцидент CDN читается в заголовках и трейсах: заголовок Vary с User-Agent или Cookie фрагментирует cache key на запрос и обваливает hit rate; max-age плюс stale-while-revalidate и stale-if-error задают окно свежести, безопасное к stampede окно stale и fallback на сбой; worker edge-композиции должен распараллелить свои fetch и ограничить волатильный таймаутом и fallback; а HIT с age меньше max-age означает устаревший деплой, который снимет только purge. Диагностируй по артефакту, применяй фикс с наибольшим рычагом, затем перепроверь тот же заголовок.