---
aliases:
  - инвалидации кэша
tags:
  - maturity/🌱
date:
  - - 2024-06-18
zero-link:
  - "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
  - "[[../Кэширование|Кэширование]]"
linked:
---
Если мы закэшировали какие-то данные, например, выборку из БД, рано или поздно исходные данные изменяются, и кэш перестает быть валидным. Причем очень желательно, чтобы кэш сбрасывался сразу же за изменением.

**Способы инвалидации:**
- Задать срок жизни - TTL. 
	- Самая простая реализация.   
	- При малом TTL будет высокий [CacheMissRate](CacheMissRate.md)
	- При большом TTL данные могут быть не консистентны
- Инвалидация по событию
	- Удаляем старые данные при изменении в базе или по событию от кафки.
	- Опасно из-за риска мгновенной инвалидации и сопутствующей [[Перестройка кэша|перестройки кэша]]
- Использование [[../../algorithm/Алгоритмы вытеснения|алгоритмов вытеснения]]

Дополнительно для работы со статическими файлами можно отменить [[../Fingerprint|Fingerprint]].

Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари. При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей. В оценке эффективности кэша поможет метрика [[CacheMissRate]].

Некоторые чувствительные данные нужно инвалидировать сразу при изменении. Тут может помочь тегирование ключей.
***
## Мета информация
**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**:: [[../Кэширование|Кэширование]]
**Источник**:: 
**Автор**:: 
**Создана**:: [[2024-06-18]]
### Дополнительные материалы
- 
### Дочерние заметки
```dataview
LIST 
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```