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

66 lines
4.4 KiB
Markdown
Raw Normal View History

2024-09-11 21:28:43 +03:00
---
aliases:
- инвалидации кэша
tags:
- maturity/🌱
date:
- - 2024-06-18
zero-link:
- "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
- "[[../Кэширование|Кэширование]]"
linked:
---
Если мы закэшировали какие-то данные, например, выборку из БД, рано или поздно исходные данные изменяются, и кэш перестает быть валидным. Причем очень желательно, чтобы кэш сбрасывался сразу же за изменением.
**Способы инвалидации:**
- Задать срок жизни - TTL.
- Самая простая реализация.
- При малом TTL будет высокий [CacheMissRate](CacheMissRate.md)
- При большом TTL данные могут быть не консистентны
- Инвалидация по событию
- Опасно из-за риска мгновенной инвалидации и сопутствующей [[Перестройка кэша|перестройки кэша]]
- Использование [[../../algorithm/Алгоритмы вытеснения|алгоритмов вытеснения]]
2024-09-13 07:09:47 +03:00
Дополнительно для работы со статическими файлами можно отменить [[../Fingerprint|Fingerprint]].
2024-09-11 21:28:43 +03:00
## Инвалидация по TTL
Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари.
2024-09-11 21:28:43 +03:00
При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей. В оценке эффективности кэша поможет метрика [[CacheMissRate]].
2024-09-14 22:17:56 +03:00
## Инвалидация по событию
В этом случае мы удаляем данные кэша по какому-то событию. Например, при вызове метода обновления данных можно удалить кэш, который связан с этими данными. В некоторых случаях можно не удалять, а сразу класть новые данные в кэш, если понимаете, что они скоро потребуются.
2024-09-14 22:17:56 +03:00
Инвалидацию по событию можно комбинировать с TTL. В таком случае при запросе данных из кэша можно проверять оставшееся время жизни, и если оно меньше, чем некоторое заданное значение, то установить TTL заново. Таким образом данные остаются в кэше, если ими активно пользуются.
2024-09-14 22:17:56 +03:00
Пример реализации механизма обновления 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;
```
2024-09-11 21:28:43 +03:00
***
## Мета информация
**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**:: [[../Кэширование|Кэширование]]
**Источник**::
**Автор**::
**Создана**:: [[2024-06-18]]
### Дополнительные материалы
-
### Дочерние заметки
2024-09-14 23:38:42 +03:00
<!-- 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 -->