34 lines
2.4 KiB
Markdown
34 lines
2.4 KiB
Markdown
|
---
|
|||
|
|
aliases:
|
|||
|
|
tags:
|
|||
|
|
- зрелость/🌱
|
|||
|
|
date:
|
|||
|
|
- - 2024-06-18
|
|||
|
|
zero-link:
|
|||
|
|
- "[[00 HighLoad]]"
|
|||
|
|
parents:
|
|||
|
|
- "[[Кэширование]]"
|
|||
|
|
linked:
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
Если мы закэшировали какие-то данные от backend’а, например, выборку из БД, рано или поздно исходные данные изменяются, и кэш перестает быть валидным. Причем очень желательно, чтобы кэш сбрасывался сразу же за изменением.
|
|||
|
|
|
|||
|
|
Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари. При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей.
|
|||
|
|
|
|||
|
|
Первый вариант не подходит. Некоторые чуствительные данные нужно инвалидировать их сразу при изменении. Тут может помочь тегирование ключей.
|
|||
|
|
|
|||
|
|
**Способы инвалидации:**
|
|||
|
|
- По истечению срока жизни - TTL.
|
|||
|
|
- Самый простой способ.
|
|||
|
|
- При малом TTL можно
|
|||
|
|
- Принудительный вызов команды инвалидации.
|
|||
|
|
- Алгоритмы вытеснения
|
|||
|
|
|
|||
|
|
Алгоритмы вытеснения:
|
|||
|
|
- Алгоритм Белади. Несуществующий идеальный алгоритм. Храним только нужную информацию, не нужную не храним.
|
|||
|
|
- [Least Recently Used](Least%20Recently%20Used.md)
|
|||
|
|
- [Most Recently Used](Most%20Recently%20Used.md)
|
|||
|
|
- [Last Frequently Used](Last%20Frequently%20Used.md)
|
|||
|
|
- [Adaptive Replacement Cache](Adaptive%20Replacement%20Cache.md)
|
|||
|
|
|
|||
|
|
- [Перестройка кэша](Перестройка%20кэша.md)
|