digital-garden/dev/architecture/highload/Инвалидация кэша.md

---
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
Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари.

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

Инвалидацию по событию можно комбинировать с TTL. В таком случае при запросе данных из кэша можно проверять оставшееся время жизни, и если оно меньше, чем некоторое заданное значение, то установить TTL заново. Таким образом данные остаются в кэше, если ими активно пользуются.

Пример реализации механизма обновления TTL на Lua:
```lua
local key = KEYS[1];
local threshold = tonumber(ARGV[1]);
local new_ttl = tonumber(ARGV[2]);
local value = redis.call('get', key);
if value then
	local ttl = redis.call('pttl', key);
	if ttl >= 0 and ttl <= threshold then
		redis.call('pexpire', key, new_ttl);
	end;
end;
return value;
```
***
## Мета информация
**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**:: [[../Кэширование|Кэширование]]
**Источник**:: 
**Автор**:: 
**Создана**:: [[2024-06-18]]
### Дополнительные материалы
- 
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
- [[Алгоритм вытеснения кэша]]
- [[Fingerprint]]
<!-- SerializedQuery END -->