Сначала найдите источник истины
В учебной модели цена товара хранится в основной базе, а кэш содержит её копию. При запросе приложение ищет подходящую запись в кэше. Если её нет, читает источник, сохраняет полученный результат и возвращает ответ. Это один распространённый подход, а не единственная возможная архитектура. Важно заранее определить, что произойдёт при отсутствии кэшированной записи. Для восстановимых копий потеря кэша обычно должна вести к повторному получению данных, а не к потере единственного экземпляра информации.
Ключ должен различать разные ответы
Если результат зависит от товара, языка и валюты, один только номер товара может оказаться недостаточным ключом. Ответы для разных условий нельзя случайно смешивать. Ещё внимательнее нужно относиться к персональным данным и правам доступа. Общий кэш не должен превращать ответ одному пользователю в ответ другому. На уровне веба существуют разные правила для частного и разделяемого кэширования. Выбор места хранения и политики должен соответствовать содержимому, а не только желанию повысить долю попаданий.
Срок хранения не замечает каждое изменение
Предположим, в источнике цена изменилась со ста до ста двадцати, а кэшированная копия ещё содержит сто. Пока приложение считает эту запись пригодной, читатель может получить старое значение. Ограниченный срок жизни уменьшает длительность некоторых таких ситуаций, но сам не сообщает кэшу о каждом обновлении. При изменении источника можно предусмотреть обновление или признание соответствующей копии недействительной. В системах с параллельными запросами и несколькими экземплярами приложения согласованность требует отдельного проектирования; простая схема не гарантирует мгновенной свежести повсюду.
Измеряйте пользу вместе с корректностью
Высокая доля попаданий не является единственной целью. Следите также за временем ответа, нагрузкой на источник, объёмом хранилища и случаями устаревших данных. Слишком короткое хранение может часто возвращать приложение к исходным запросам, а слишком долгое увеличивать риск неактуального результата. Разным данным могут требоваться разные правила. Картинка интерфейса, справочное описание и персональный остаток не обязаны кэшироваться одинаково. Операции, которым нужна актуальная информация, должны иметь явно определённый способ её получения и проверки.
Попробуйте на практике
Составьте бумажную модель кэша для вымышленного каталога, не меняя реальные настройки сервиса и не используя персональные данные.
- Нарисуйте три элемента: приложение, кэш и основной источник. Укажите, где находится исходная цена и как приложение действует при отсутствии копии.
- Запишите два запроса к одному товару с разной валютой. Объясните, какие части ключа должны различаться, чтобы ответы не смешались.
- Проведите последовательность: чтение цены сто, сохранение копии, изменение источника на сто двадцать и повторное чтение. Покажите место возможного устаревшего ответа.
- Добавьте правило обновления либо признания копии недействительной. Отдельно перечислите вопросы о параллельных запросах, сроке жизни и доступе, которые простая схема ещё не решает.
Как проверить результат. Вы можете объяснить происхождение старого значения, различие ключей и способ восстановления отсутствующей копии. В модели нет обещания, что один срок жизни автоматически обеспечивает полную согласованность.
Частые вопросы
Нужно ли кэшировать всё дорого вычисляемое?
Не обязательно. Учитывайте частоту повторного использования, стоимость хранения, допустимую неактуальность и ограничения доступа. Иногда расходы и сложность обновления превышают пользу.
Очистка кэша исправляет причину старых данных?
Она может временно убрать симптом, но не заменяет правильные ключи и правила обновления. Если причина остаётся, та же ситуация способна повториться.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.