Как обеспечивать инвалидность кэша при его невалидности
Что проверяют
Понимаете ли вы, что кеш это компромисс между свежестью и нагрузкой, и знаете ли способы его сброса. Для тестировщика ещё и то, как проверять такие сценарии.
Как отвечать
Способы поддерживать актуальность:
- срок жизни: запись живёт заданное время. Просто и надёжно, но данные какое-то время устаревшие. Подходит для того, что меняется редко;
- сброс по событию: изменили сущность, удалили или обновили её запись в кеше. Точно, но требует найти все места, где эта сущность закешированa, и легко пропустить одно;
- версия в ключе: ключ включает версию данных или метку изменения, поэтому старые записи просто перестают запрашиваться и вытесняются сами. Удобно для составных ключей вроде списков с фильтрами;
- запись через кеш: обновление идёт одновременно в хранилище и в кеш, поэтому рассинхронизации почти нет;
- тегирование: записи помечаются тегами (например, идентификатором компании), и сброс идёт по тегу целиком.
Отдельно стоит назвать проблему одновременного промаха: истёк срок у популярного ключа, и сотня запросов одновременно пошла в базу. Лечится блокировкой на пересчёт, фоновым обновлением до истечения срока или небольшим случайным разбросом срока жизни.
Для тестировщика важно проверять: видит ли пользователь свои изменения сразу; не показывается ли чужое из-за общего ключа (классическая утечка, когда персональные данные попали в общий кеш); что происходит при недоступности кеша, отвечает ли система из хранилища; сбрасывается ли кеш при выкате новой версии, если формат данных изменился.
Где спотыкаются
Кешируют персональный ответ по общему ключу и показывают одному пользователю данные другого.
Сбрасывают кеш в одном месте из трёх и получают воскрешающиеся старые данные.
Считают кеш источником истины и падают целиком, когда он недоступен.