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