Кеширование
Уровни кэша: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — лестница задержек, где кэшировать, точка окупаемости hit ratio и сбои wrong-layer и double-caching.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальной системе — не определение для заучивания, а компромисс, который надо взвесить, как только кто-то скажет «просто добавь кэш».
Цель
Убедись, что связываешь лестницу задержек, выбор слоя для кэша, точку окупаемости hit ratio и сбои wrong-layer и double-caching — тот синтез, к которому вёл урок.
Викторина
Completed
Команда ставит in-region Redis cache (~1 мс round trip) перед primary-key lookup в Postgres (тёплый, отдаётся из buffer pool за ~0.3 мс). p99 чтения растёт. Почему?
Heads-up Redis быстр и фактически неблокирующий для простых GET; пропускная способность тут не проблема. Задержка выросла, потому что сетевой round trip к Redis медленнее тёплого чтения из buffer pool, перед которым он стоит.
Heads-up Redis работает как отдельный процесс / инстанс и не уменьшает buffer pool Postgres. Регрессия — это добавленный сетевой хоп на пути, который и так был попаданием в RAM.
Heads-up Хэширование ключа — это наносекунды, ничто рядом с ~1 мс сетевого round trip. Структурная ошибка — поставить cache на скорости сети перед origin на скорости RAM.
Викторина
Completed
Эндпоинт чтения выполняет join по 3 таблицам за 80 мс, вызывается 50×/сек, данные меняются пару раз в день. Где должен быть cache?
Heads-up Нижние слои помогают I/O-bound чтениям, но 80 мс — это работа CPU (join и агрегация), а не чтения с диска. Page cache делает строки быстрыми для выборки, но не может пропустить пересчёт join-а. Нужно кэшировать вычисленный результат.
Heads-up Неверный слой для эндпоинта данных. CDN ключуется по URL и предназначен для статичных или почти статичных ответов; длинный edge TTL означает, что изменение данных проявится глобально только по истечении, а персонализированные варианты утекут между пользователями.
Heads-up 50 вызовов/сек по 80 мс — это реальная нагрузка на origin и реальный хвост задержки, а данные терпят устаревание. Это чистый кейс для кэша; пропуск меняет дешёвую понятную победу на лишнее давление на origin.
Викторина
Completed
Cache с hit ratio 35% стоит перед origin в 80 мс за lookup-ом в 1 мс. Средняя задержка 0.35×1 + 0.65×(1+80) ≈ 53 мс — лучше, чем 80. Почему hit ratio 35% всё равно тревожный сигнал?
Heads-up Среднее улучшается лишь потому, что origin достаточно медленный, чтобы поглотить налог за miss, но переиспользование в 35% — слабое: miss-ы всё равно платят cache+origin, а ты купил новую движущуюся часть и путь инвалидации ради тонкой и хрупкой к смене трафика выгоды.
Heads-up Hit ratio — это именно то число, что оправдывает cache. Ниже точки окупаемости налог за miss (cache lookup плюс полный origin) делает cache строго хуже, чем его отсутствие.
Heads-up Низкий hit ratio — это сигнал о профиле нагрузки / дизайне ключей (одноразовые ключи, слишком короткий TTL, плохая кардинальность ключей), а не баг стабильности. Он говорит, что cache может не стоить своей цены здесь.
Викторина
Completed
Почему OS page cache — самый недооценённый слой при решении, добавлять ли Redis?
Heads-up Page cache хранит сырые страницы файлов, а не сжатые данные, и дело не в этом. Его ценность в том, что горячие чтения отдаются из RAM без усилий с твоей стороны, поэтому origin может уже быть на скорости RAM.
Heads-up Page cache локальный и привязан к одной машине — его нельзя разделить между инстансами, а именно это добавляет application cache. Его значимость здесь в том, что он делает горячие чтения одного узла быстрыми, как RAM.
Heads-up Page cache — про задержку чтения, а не про свежесть, и поддерживается когерентным через файловую систему. Важен он здесь тем, что делает origin быстрым, поэтому сетевой cache перед ним может добавить задержку вместо того, чтобы убрать её.
Викторина
Completed
Значение кэшируется в Redis (инвалидируется на запись) И его отрендеренный ответ кэшируется на CDN с TTL 5 минут. После записи пользователи всё ещё видят старые данные минутами. В чём сбой и каков структурный фикс?
Heads-up Redis свежий — он инвалидирован корректно. Устаревшая копия на CDN. Снижение TTL у Redis ничего не меняет, потому что лжёт слой CDN; проблема в двух нескоординированных слоях, а не в одном TTL.
Heads-up Сокращение edge TTL лишь уменьшает окно устаревания — слои всё равно нескоординированы, и запись всё равно невидима до истечения. Настоящий фикс — purge-on-write или единый владеющий слой, а не меньшее окно.
Heads-up Stale-on-stale здесь вызвано двумя независимыми слоями, кэширующими один факт, и этого можно избежать: дай каждому факту одного владельца и один путь инвалидации. Единственный корректно очищаемый слой кэша не расходится сам с собой.
Викторина
Completed
Инженер кэширует пер-пользовательский фрагмент «рекомендуем вам» на CDN, чтобы снизить нагрузку на origin. Часть пользователей начинает видеть чужие рекомендации. Корневая причина?
Heads-up Модель в порядке — фрагменты отдаются из общей записи CDN с ключом по URL, поэтому кэшированный фрагмент пользователя A возвращается пользователю B. Это ошибка слоя кэширования, а не баг модели.
Heads-up Даже если origin читает куку корректно, попадание в CDN с ключом по URL никогда не доходит до origin — он отдаёт то, что закэшировал первым. Дефект — кэширование данных, зависящих от личности, на слое, который не различает пользователей.
Heads-up Это межпользовательская утечка, а не устаревание. Более короткий TTL всё равно отдаёт фрагмент одного пользователя другому внутри окна. Персонализированные данные просто нельзя кэшировать на общем слое с ключом по URL.
Итог
Сквозная линия: кэширование — это лестница задержек (L1, RAM, page cache, Redis, CDN), и cache помогает только когда стоит перед реально более медленным origin, hit ratio высокий, а данные терпят устаревание. Page cache и buffer pool БД часто уже делают origin быстрым, как RAM, поэтому проверь реальную задержку origin, прежде чем тянуться за Redis. Senior-сбои повторяются: cache перед быстрым origin, оправдание кэша слабым hit ratio, кэширование персонализированных данных на CDN с ключом по URL и double-caching одного факта на двух слоях с независимыми TTL. Кэшируй так близко к потребителю, как позволяет волатильность данных; дай каждому факту одного владельца и один путь инвалидации.