Ответ
Инвалидация кеша — это процесс признания данных в кеше устаревшими или недействительными с последующим их удалением или обновлением. Это необходимо для обеспечения согласованности между данными в кеше и источником истины (например, базой данных).
Стратегии инвалидации с точки зрения тестирования:
- По времени (TTL): Кеш автоматически очищается через заданный интервал.
- Как тестировать: Проверяем, что после истечения TTL следующий запрос получает свежие данные из источника.
- Явная инвалидация: Приложение отправляет сигнал на удаление записей из кеша при изменении данных.
- Как тестировать:
# Пример сценария тестирования для API # 1. Запрашиваем данные, они попадают в кеш response1 = get('/product/123') # 2. Изменяем данные продукта (этот вызов должен инвалидировать кеш) put('/product/123', {'price': 999}) # 3. Снова запрашиваем данные — должны получить обновлённую цену, а не закешированный старый вариант response2 = get('/product/123') assert response2.json()['price'] == 999
- Как тестировать:
- Инвалидация по событию: Кеш очищается в ответ на события в системе (например, публикация нового контента).
Роль QA: Тестировщик должен проектировать тесты, которые проверяют не только скорость работы кеша, но и корректность его инвалидации, чтобы избежать ситуаций, когда пользователь видит устаревшую информацию.
Ответ 18+ 🔞
Давай разберём эту тему про инвалидацию кеша, а то звучит как диагноз, но на деле всё проще, чем кажется.
Представь, что кеш — это твой друг, который очень любит сплетни. Он услышал какую-то новость (данные из базы) и теперь всем её рассказывает. А потом база, эта самая первоисточница, взяла и информацию обновила. А твой друг-сплетник всё старую версию талдычит. Вот чтобы он не позорился и не вводил народ в заблуждение, его надо вовремя инвалидировать — то есть дать по башке и заставить актуализировать инфу. Или просто забыть всё и переспросить.
Стратегии, как этого друга приводить в чувство:
-
По времени (TTL). Это как поставить ему будильник: «Через пять минут всё, что ты помнишь — хуйня, иди перепроверь». Самый простой способ, но туповатый. Вдруг данные поменялись через минуту, а он ещё четыре будет ерунду нести.
- Как на это смотреть: Ждём, пока время истечёт, дергаем данные и смотрим — принёс ли наш кеш-сплетник свежую порцию правды из базы, или продолжает старую петь.
-
Явная инвалидация. Вот это уже осознанное действие. Приложение само, как хороший товарищ, подходит к кешу и говорит: «Слушай, чувак, всё, что ты знал про продукт №123 — пиздец, забудь. Там теперь по-другому». И кеш послушно стирает это из памяти.
- Как это ломать (в хорошем смысле, тестировать):
# 1. Сначала вытягиваем данные. Они спокойно себе засядут в кеш. response1 = get('/product/123') # 2. Меняем что-то в этом продукте. КРИТИЧНО ВАЖНЫЙ МОМЕНТ: этот вызов должен дать пизды кешу по конкретному ключу. put('/product/123', {'price': 999}) # 3. И сразу же запрашиваем снова. Если всё сделано правильно, мы должны увидеть новую цену (999), а не старую закешированную хуйню. response2 = get('/product/123') assert response2.json()['price'] == 999 # Вот тут либо зелёный тест, либо волнение ебать.Если тест красный — значит, наш кеш упёртый говноед и продолжает показывать старьё. Пиздец, а не фича.
- Как это ломать (в хорошем смысле, тестировать):
-
По событию. Типа «как только админ нажал «Опубликовать», весь кеш для ленты новостей накрылся медным тазом». Автоматическая реакция на триггер в системе.
А теперь, блядь, самое важное — роль QA в этой движухе.
Наша задача — не просто проверить, что с кешом всё быстро работает. Ёпта, с кешем и так всё быстро. Наша цель — устроить ему адскую жизнь. Убедиться, что в момент, когда данные поменялись, этот хитрожопый кеш не подсовывает пользователям вчерашние объедки. Нужно проектировать тесты, которые ловят эти моменты рассинхрона. Потому что если пользователь видит старую цену, старый баланс или старый пост — это не баг, это пиздец, доверия ебать ноль. Вот за этим мы и следим, чтобы сплетник-кеш всегда был в тонусе и не нес хуйню.