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