Уровни кэша: тест с выбором ответа
Тест с выбором на синтез по всему юниту — лестница задержек, где кэшировать, точка окупаемости hit ratio и сбои wrong-layer и double-caching.
Шесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальной системе — не определение для заучивания, а компромисс, который надо взвесить, как только кто-то скажет «просто добавь кэш».
Убедись, что связываешь лестницу задержек, выбор слоя для кэша, точку окупаемости hit ratio и сбои wrong-layer и double-caching — тот синтез, к которому вёл урок.
Команда ставит in-region Redis cache (~1 мс round trip) перед primary-key lookup в Postgres (тёплый, отдаётся из buffer pool за ~0.3 мс). p99 чтения растёт. Почему?
Эндпоинт чтения выполняет join по 3 таблицам за 80 мс, вызывается 50×/сек, данные меняются пару раз в день. Где должен быть cache?
Cache с hit ratio 35% стоит перед origin в 80 мс за lookup-ом в 1 мс. Средняя задержка 0.35×1 + 0.65×(1+80) ≈ 53 мс — лучше, чем 80. Почему hit ratio 35% всё равно тревожный сигнал?
Почему OS page cache — самый недооценённый слой при решении, добавлять ли Redis?
Значение кэшируется в Redis (инвалидируется на запись) И его отрендеренный ответ кэшируется на CDN с TTL 5 минут. После записи пользователи всё ещё видят старые данные минутами. В чём сбой и каков структурный фикс?
Инженер кэширует пер-пользовательский фрагмент «рекомендуем вам» на CDN, чтобы снизить нагрузку на origin. Часть пользователей начинает видеть чужие рекомендации. Корневая причина?
Сквозная линия: кэширование — это лестница задержек (L1, RAM, page cache, Redis, CDN), и cache помогает только когда стоит перед реально более медленным origin, hit ratio высокий, а данные терпят устаревание. Page cache (кэш страниц ОС, хранящий горячие файлы в RAM) и buffer pool БД часто уже делают origin быстрым, как RAM, поэтому проверь реальную задержку origin, прежде чем тянуться за Redis. Senior-сбои повторяются: cache перед быстрым origin, оправдание кэша слабым hit ratio, кэширование персонализированных данных на CDN с ключом по URL и double-caching одного факта на двух слоях с независимыми TTL. Теперь, когда кто-то предложит новый слой кэша, у тебя есть шесть вопросов чтобы проверить его — компромиссы каждый раз одни и те же.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.