Стратегии кэширования
Тема дорожной карты · Backend разработчик
Стратегии кеширования — это паттерны и политики, определяющие, как, когда и на какое время данные сохраняются в быстром промежуточном слое — обычно Redis или кеше в памяти процесса — для снижения задержки и разгрузки PostgreSQL, MySQL или внешних API. Четыре фундаментальные стратегии кеширования: Cache-Aside (ленивая загрузка: приложение читает из кеша, при промахе обращается к базе данных и записывает результат в кеш), Write-Through (синхронная двойная запись одновременно в кеш и базу данных при каждом обновлении), Write-Behind (асинхронная запись в базу данных после подтверждения записи в кеш, улучшающая пропускную способность записи ценой кратковременной несогласованности) и Read-Through (слой кеша сам прозрачно обращается к базе данных). HTTP-кеширование добавляет ещё одно измерение: Cache-Control: max-age=3600 даёт браузерам и CDN-узлам (Cloudflare, Fastly) указание отдавать кешированные ответы, тогда как заголовки ETag и Last-Modified позволяют условным запросам возвращать 304 Not Modified, не передавая тело повторно. Инвалидация кеша — сложная задача — управляется явными TTL (SET key value EX 600 в Redis), событийными очистками, инициируемыми доменными событиями в Kafka или RabbitMQ, и тегированием кеша в системах вроде Varnish или proxy_cache_purge в Nginx. Выбор подходящей стратегии кеширования требует анализа соотношения операций чтения/записи, допустимой «устарелости» данных и требований к согласованности: высокочитаемый, редко обновляемый контент (каталоги товаров, узлы дорожной карты) хорошо подходит для агрессивного Cache-Aside с длинными TTL, тогда как пользовательские или финансовые данные требуют коротких TTL или Write-Through во избежание отдачи устаревшего состояния.
Как это работает
Стратегии кэширования использует кеши (Redis, Memcached, in-process LRU) чтобы избежать дорогого DB или compute, и очереди (Redis Streams, RabbitMQ, Kafka, SQS) чтобы развязать медленную async-работу от request-пути. Стратегии инвалидации кеша: TTL (истечение по времени), write-through (обновлять кеш на запись), event-driven (инвалидация на связанное изменение), cache-aside (читаем кеш, fallback на БД). Паттерны очередей: work queues, pub/sub, exactly-once vs at-least-once.
Когда применять
Кеш — когда замер показывает повтор дорогого compute; никогда "превентивно". TTL-кеш — для данных с допустимой staleness (5-60 секунд закрывает большинство кейсов). Очереди — когда запрос триггерит работу, не помещающуюся в response window (отправка email, обработка файлов, вызовы third-party): возвращайте 202 Accepted + status URL. Consumers очередей — это сервисы со своим мониторингом + репликами.
Типичные ошибки
Ловушки Стратегии кэширования: stale-кеш, потому что забыли инвалидировать на связанном пути (знаменитая "две сложные проблемы"); cache stampede, когда ключ протух и N запросов одновременно бьют в БД (stale-while-revalidate или singleflight); at-least-once очереди без идемпотентных consumer (дубль emails/charges); не мониторите lag очереди (тихий backlog растёт, потом взрывается).