Инвалидация кэша.md
All checks were successful
continuous-integration/drone/push Build is passing

This commit is contained in:
Struchkov Mark 2024-09-14 22:17:56 +03:00
parent 4a1d913afa
commit 293900bece
No known key found for this signature in database
GPG Key ID: A3F0AC3F0FA52F3C
3 changed files with 6 additions and 6 deletions

View File

@ -19,7 +19,6 @@ linked:
- При малом TTL будет высокий [CacheMissRate](CacheMissRate.md) - При малом TTL будет высокий [CacheMissRate](CacheMissRate.md)
- При большом TTL данные могут быть не консистентны - При большом TTL данные могут быть не консистентны
- Инвалидация по событию - Инвалидация по событию
- Удаляем старые данные при изменении в базе или по событию от кафки.
- Опасно из-за риска мгновенной инвалидации и сопутствующей [[Перестройка кэша|перестройки кэша]] - Опасно из-за риска мгновенной инвалидации и сопутствующей [[Перестройка кэша|перестройки кэша]]
- Использование [[../../algorithm/Алгоритмы вытеснения|алгоритмов вытеснения]] - Использование [[../../algorithm/Алгоритмы вытеснения|алгоритмов вытеснения]]
@ -29,11 +28,12 @@ linked:
Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари. Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари.
При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей. В оценке эффективности кэша поможет метрика [[CacheMissRate]]. При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей. В оценке эффективности кэша поможет метрика [[CacheMissRate]].
## Инвалидация по событию
В этом случае мы удаляем данные кэша по какому-то событию. Например, при вызове метода обновления данных можно удалить кэш, который связан с этими данными. В некоторых случаях можно не удалять, а сразу класть новые данные в кэш, если понимаете, что они скоро потребуются.
Если просто установить TTL, то спустя какое-то время он истечет и данные будут удалены, но что если к ним постоянно обращаются. В некоторых случаях я использую подход, при котором при запросе данных из кэша проверяется оставшийся TTL, и если он меньше, чем некоторое значение, то TTL устанавливается заново. Инвалидацию по событию можно комбинировать с TTL. В таком случае при запросе данных из кэша можно проверять оставшееся время жизни, и если оно меньше, чем некоторое заданное значение, то установить TTL заново. Таким образом данные остаются в кэше, если ими активно пользуются.
Данные остаются в кэше, если ими активно пользуются. В таком случае при обновлении данных, необходимо вручную положить новые данные или инвалидировать кэш по событиям.
Пример реализации механизма обновления TTL на Lua:
```lua ```lua
local key = KEYS[1]; local key = KEYS[1];
local threshold = tonumber(ARGV[1]); local threshold = tonumber(ARGV[1]);

View File

@ -3,7 +3,7 @@ aliases:
- метапознание - метапознание
tags: tags:
- maturity/🌱 - maturity/🌱
date: "[[2023-10-28]]" date: 2023-10-28
zero-link: zero-link:
- "[[../meta/zero/00 Образование|00 Образование]]" - "[[../meta/zero/00 Образование|00 Образование]]"
parents: parents:

View File

@ -3,7 +3,7 @@ aliases:
- СБН - СБН
tags: tags:
- maturity/🌱 - maturity/🌱
date: "[[2023-10-26]]" date: 2023-10-26
zero-link: zero-link:
- "[[../../meta/zero/00 Здоровье|00 Здоровье]]" - "[[../../meta/zero/00 Здоровье|00 Здоровье]]"
parents: parents: