Практикум модуля 2

Итоговая практика кеширования: от корректной обёртки до аварийной ситуации и её расследования.

Задание 1. Продакшн-обёртка кеша

Напишите на своём языке класс/модуль SmartCache с:

• cache-aside чтением с TTL и джиттером;
• мьютексом против stampede (SET NX EX);
• null-кешированием несуществующих значений;
• метриками: hits, misses, recompute_count, avg_compute_ms (в счётчиках Redis или логах).

Проверка корректности: 10 параллельных процессов, compute с задержкой 1с — при каждом истечении TTL compute должен вызваться ровно один раз.

Задание 2. Eviction под давлением

redis-cli CONFIG SET maxmemory 100mb
redis-cli CONFIG SET maxmemory-policy allkeys-lru
redis-benchmark -n 3000000 -t set -d 64 -q        # залить больше, чем память
redis-cli INFO stats | grep -E 'evicted_keys|keyspace'
redis-cli CONFIG SET maxmemory-policy allkeys-lfu
# повторить с неравномерным доступом: 90% обращений на 1% ключей
redis-benchmark -n 1000000 -t get -c 20 --keyspacelen 30000 -q

Сравните hit rate LRU против LFU при «горячей головке» распределения. Оформите вывод одним абзацем — какой политике верить и почему.

Задание 3. Расследование инцидента (по сценарию)

Ситуация: ночью нагрузка на БД выросла ×10, hit rate кеша упал с 92% до 40%, evicted_keys растёт. У вас есть только redis-cli. Ваш план расследования:

1. INFO memory — maxmemory достигнут?
2. INFO stats — evicted_keys растёт? hit rate по времени?
3. Появились ли новые префиксы ключей (SCAN MATCH)? Может, кто-то закешировал «хвост»;
4. redis-cli --bigkeys — не появились гиганты;
5. Дифф TTL-классов: SAMPLE ключей по префиксам → TTL — не изменил ли кто-то TTL-политику.

Прогоните сценарий в лаборатории: залейте «правильный» кеш, затем «поломайте» (новый префикс без TTL, выжав память), и найдите причину по своему же плану.

Задание 4. TTL-матрица для своего домена

Выпишите 5–10 классов данных вашего приложения и для каждого: требование к свежести, TTL, стратегию инвалидации, ожидаемый hit rate. Это готовый фрагмент дизайн-дока вашего кеша.