Цена в карточке обновилась, а список продолжает показывать старое значение. Ускорение чтения создало несколько представлений одного объекта. Корректность кеша начинается с определения допустимого устаревания и полного набора ключей, связанных с изменением.
Что подготовить
- Источник истины, все кеширующие слои и правила формирования ключей.
- Требования к допустимому устареванию для каждого типа данных.
- Пути записи, удаления и массового обновления, включая административные операции.
Порядок работы
- Опишите, что именно хранится: объект, готовый ответ или результат запроса. Найдите параметры, влияющие на содержимое ключа.
- Проверьте включение организации, языка, фильтров и прав доступа там, где они меняют ответ.
- Для каждой записи определите механизм обновления или удаления затронутых ключей и поведение при сбое этого механизма.
- Воспроизведите конкурентное чтение во время обновления, чтобы устаревший ответ не вернулся в кеш после удаления.
- Проверьте холодный старт и массовое истечение срока. Ограничьте одновременное восстановление одного дорогостоящего значения.
Разобранный пример
Список товаров кешируется по категории и языку, а карточка — по идентификатору. Изменение названия требует обновить карточку и затронутые списки. Если список хранит только идентификаторы, а названия подставляются отдельно, набор зависимостей другой. Проверка должна соответствовать фактической структуре.
Как проверить результат
- Данные разных пользователей или организаций не смешиваются в одном ключе.
- Обновление становится видимым в пределах заявленного времени.
- Недоступность кеша приводит к предусмотренному режиму, а не бесконтрольному потоку в базу.
Если что-то пошло не так
Если инвалидировать все производные ключи надежно невозможно, рассмотрите версионирование пространства ключей или ограниченный срок жизни. Для критичных решений читайте авторитетное состояние в точке действия, даже если интерфейс использует допускающий устаревание кеш.
Разбор гонки обновления кеша
Нарисуйте последовательность из трех участников: читатель, писатель и хранилище кеша. Читатель начал получать старые данные; писатель изменил источник и удалил ключ; читатель завершил старое чтение и снова записал устаревшее значение. Такой порядок показывает, почему одного удаления после записи иногда недостаточно. Проверка должна управляемо воспроизвести именно эту последовательность.
Вариант решения выбирайте по требованиям: проверка версии перед публикацией, пространство ключей с версией либо другой согласованный механизм. В отчете укажите, какое состояние может увидеть пользователь и как долго. Если допускается краткое устаревание списка, это не означает, что тот же допуск подходит для проверки остатка при оформлении заказа.
Составьте реестр зависимостей: событие изменения, затронутый объект, ключ карточки, ключи списков и способ их обнаружения. Для массового изменения проверьте предел объема работы: миллионы отдельных удалений могут оказаться непрактичными. Для ошибки кеша отдельно задайте ограничение нагрузки на источник. Тест восстановления должен убедиться, что после возвращения кеша приложение не наполняет его данными из старого локального состояния и не запускает одновременно неограниченное число одинаковых вычислений.
Промпт для разбора ваших материалов
Построй карту кешей по описанию приложения. Для каждого ключа перечисли влияющие параметры, источник истины и механизм актуализации. Подготовь сценарии конкурентного чтения, ошибки инвалидирования и холодного старта.Частые вопросы
Можно ли просто уменьшить срок жизни?
Это ограничит длительность устаревания, но увеличит обращения к источнику и не исправит неверный состав ключа.
Нужно ли кешировать ошибки?
Только по явному правилу с подходящим сроком и областью действия. Иначе временная ошибка может пережить восстановление источника.
Материал библиотеки решений Ильи Тарасова / TarasovWeb.
О проекте
Практическая библиотека Ильи Тарасова и TarasovWeb. Telegram-канал · Личная страница · ВКонтакте.
#tarasovweb #ИльяТарасов