Cache hit (попадание в кэш) и cache miss (промах кэша) — два базовых состояния системы кэширования. При cache hit данные уже хранятся в быстром промежуточном хранилище (кэше), и система возвращает их немедленно. При cache miss кэш не содержит актуальной версии данных — система запрашивает их из медленного источника (база данных, диск, удалённый сервер) и опционально сохраняет результат в кэш.
Как работает на практике
Метрика hit rate (процент cache hit от всех запросов) — ключевой показатель эффективности кэша. Для Redis и Memcached hit rate <80% сигнализирует о проблеме: либо TTL слишком короткий, либо объём кэша недостаточен, либо ключи генерируются непоследовательно. Hit rate 95%+ считается нормой для сессионного кэша.
Для CDN hit rate измеряется иначе — как отношение запросов, обслуженных edge-узлом, к общему числу запросов. Cloudflare отображает это в дашборде как «Cache Rate». Низкий cache hit у CDN означает частые запросы к origin-серверу, что увеличивает задержку и нагрузку.
Процессорные кэши (L1/L2/L3) работают по тем же принципам, но на наносекундном уровне. Cache miss на уровне L1 (задержка ~4 нс) vs обращение к RAM (60–100 нс) даёт разницу в 15-25x по времени доступа. Cache miss до диска — разница в 100 000x.
История
Концепция кэш-памяти появилась в 1960-х годах вместе с развитием компьютерной архитектуры. Первый аппаратный кэш внедрила IBM в мейнфрейме IBM System/360 Model 85 в 1968 году. Термины «cache hit» и «cache miss» закрепились в академической литературе 1970-х при исследовании иерархии памяти. С появлением веб-кэшей в 1990-х те же термины перешли в HTTP-протокол и CDN-индустрию.
Типы cache miss
- Cold miss (compulsory miss) — первое обращение к данным, кэш ещё не заполнен. Неизбежен при старте сервиса.
- Capacity miss — кэш заполнен, данные вытеснены по политике (LRU, LFU). Решение: увеличить размер кэша.
- Conflict miss — в ассоциативных кэшах данные вытесняют друг друга из-за коллизий хешей.
- Coherence miss — данные инвалидированы из-за обновления на другом узле (актуально для распределённых кэшей).
На что обращать внимание
Cache stampede (thundering herd) — ситуация, когда массовый cache miss происходит одновременно у тысяч запросов (например, после сброса кэша). Все запросы бегут к базе данных одновременно, что приводит к перегрузке. Решение: probabilistic early expiration (заранее обновлять кэш до истечения TTL) или mutex-блокировка при регенерации записи.
В Nginx cache hit/miss отображается в заголовке ответа X-Cache-Status: HIT / MISS / BYPASS / EXPIRED. Мониторинг этого заголовка через лог-анализ позволяет выявлять некэшируемые ресурсы без специального инструментария.
Метрики эффективности кэша
Ключевая метрика — hit rate (процент попаданий): hit rate = cache hits / (cache hits + cache misses) × 100%. Hit rate 90% означает, что 9 из 10 запросов обслуживаются из кэша без обращения к источнику. Для CDN типичный целевой hit rate — 85-95%. Для базы данных в памяти (Redis) — 95-99%.
Вторая метрика — TTFB (Time to First Byte) при cache hit vs cache miss. Cache hit на CDN-сервере даёт TTFB 5-20 мс, cache miss требует обращения к origin-серверу — 50-500 мс. Разница в 10-25 раз объясняет важность высокого hit rate для производительности.
Причины cache miss
- Cold start (холодный старт) — кэш только запустился, данных нет. Первые запросы всегда промахи.
- Cache eviction — данные вытеснены из кэша из-за нехватки места (LRU, LFU политики).
- Cache invalidation — данные устарели и удалены после обновления источника.
- Cache bypass — запрос намеренно обходит кэш (заголовок
Cache-Control: no-cache). - Key miss — запрошен ресурс, который никогда не кэшировался (уникальный URL с параметрами).
Thundering herd при cache miss
Thundering herd (стадо громов) — ситуация, когда кэш только очищен (после invalidation или restart), и тысячи одновременных запросов падают на origin-сервер. Все получают cache miss одновременно, создавая пиковую нагрузку, которая может положить источник. Решения: mutex lock на первый запрос (остальные ждут), stale-while-revalidate (отдавать устаревший кэш пока обновляется), background refresh.
В Nginx это решается директивой proxy_cache_lock on: только один запрос проходит к upstream при cache miss, остальные ждут результата. В Varnish — Grace mode: устаревший контент отдаётся клиентам, пока фоновый запрос обновляет кэш.
Связь с хостингом
Для хостинга hit rate — показатель правильно настроенного кэша. Низкий hit rate (<50%) говорит о проблемах: слишком короткий TTL, кэширование не настроено для статики, персонализированные URL ломают кэширование. Инструменты анализа: X-Cache заголовок в ответах (HIT/MISS), статистика Nginx (ngx_http_stub_status_module), Redis INFO stats.