Struchkov Mark
e9fc372054
All checks were successful
continuous-integration/drone/push Build is passing
66 lines
4.6 KiB
Markdown
66 lines
4.6 KiB
Markdown
---
|
||
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 -->
|
||
|