3.1 KiB
aliases | tags | date | zero-link | parents | linked | ||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
Если мы закэшировали какие-то данные, например, выборку из БД, рано или поздно исходные данные изменяются, и кэш перестает быть валидным. Причем очень желательно, чтобы кэш сбрасывался сразу же за изменением.
Способы инвалидации:
- Задать срок жизни - TTL.
- Самая простая реализация.
- При малом TTL будет высокий CacheMissRate
- При большом TTL данные могут быть не консистентны
- Инвалидация по событию
- Удаляем старые данные при изменении в базе или по событию от кафки.
- Опасно из-за риска мгновенной инвалидации и сопутствующей Перестройка кэша
- Использование ../../algorithm/Алгоритмы вытеснения
Дополнительно для работы со статическими файлами можно отменить ../../../../../_inbox/Fingerprint.
Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари. При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей. В оценке эффективности кэша поможет метрика CacheMissRate.
Некоторые чувствительные данные нужно инвалидировать сразу при изменении. Тут может помочь тегирование ключей.
Мета информация
Область:: ../../../meta/zero/00 HighLoad Родитель:: ../Кэширование Источник:: Автор:: Создана:: 2024-06-18
Дополнительные материалы
Дочерние заметки
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)