Кеширование

Снижение задержки и нагрузки: часто запрашиваемые или тяжелые данные хранятся в быстром хранилище (память, Redis). Меньше обращений к БД и внешним сервисам. Улучшение отзывчивости и пропускной способности. Применяют для результатов запросов, сессий, статики, тяжелых вычислений.

LRU (Least Recently Used) - политика вытеснения: удаляются данные, к которым дольше всего не обращались. Подходит для кеша с ограниченным размером. Реализация: хеш-таблица + двусвязный список по времени доступа, или приближенные алгоритмы. В Redis политика volatile-lru, allkeys-lru. Альтернативы: LFU (Least Frequently Used), TTL-based.

При изменении данных кеш должен обновляться или удаляться. Способы: TTL (время жизни) - данные устаревают автоматически; invalidate on write - при обновлении записи удалять/обновлять ключ; event-based - подписка на события изменения; version в ключе (cache key = "user:123:v2"). Выбор зависит от требований к консистентности и сложности.

Cache-Aside: приложение читает кеш; при промахе читает БД и кладет в кеш. Запись - в БД, затем инвалидация или обновление кеша. Write-Through: запись идет в кеш и кеш сам пишет в БД. Чтение всегда из кеша. Write-Behind: запись в кеш, асинхронная запись в БД. Cache-Aside самый распространенный; Write-Through упрощает логику приложения.

Одновременное истечение TTL у многих ключей и множество запросов вызывают "лавину" обращений к БД и перезапись кеша. Решение: блокировка (lock) - один запрос обновляет кеш, остальные ждут или читают старое; "early expiration" - обновлять до истечения в фоне; случайный разброс TTL. В распределенной среде - distributed lock (Redis).

Cache penetration: запросы по ключам, которых нет в БД (например, несуществующий id). Кеш не помогает, запросы идут в БД. Решение: кешировать "отсутствие" (null/empty с коротким TTL) или Bloom filter. Cache avalanche: массовое истечение TTL (например, кеш поднялся после сбоя) - нагрузка на БД резко растет. Решение: разброс TTL, warm-up, ограничение нагрузки.

Один или несколько ключей с очень высокой частотой запросов. Один узел кеша (или один шард) перегружается. Решения: локальный кеш перед распределенным (multi-level cache); репликация горячих ключей; разбиение ключа на несколько (sharding по ключу). Мониторинг hit rate и распределения запросов по ключам помогает выявить hot keys.

Слишком короткий TTL - много промахов и нагрузка на БД. Слишком длинный - устаревшие данные. Сложная инвалидация - баги и дублирование логики. Кеш как единственная точка отказа при сбое - перегрузка БД. Кеширование чувствительных данных без защиты - утечки. Важно: мониторинг hit rate, консистентность по требованиям, не кешировать "на всякий случай".

Memcached - только ключ-значение (строки), многопоточный, проще. Подходит для простого кеша. Redis - структуры данных (list, set, hash, sorted set), однопоточная модель, персистентность, pub/sub, Lua. Для кеша оба подходят; Redis гибче (сложные ключи, TTL на уровне поля). Выбор: Memcached для максимальной простоты и памяти; Redis для универсального кеша и других сценариев (очереди, сессии).

Redis - однопоточное выполнение команд: одна команда атомарна. Несколько команд - через MULTI/EXEC (транзакция) или Lua-скрипт (атомарное выполнение скрипта). Lua предпочтительнее для сложной логики без round-trip. WATCH - оптимистичная блокировка перед MULTI. Для распределенных блокировок - Redlock (несколько инстансов Redis).