vault backup: 2024-06-17 18:57:16

This commit is contained in:
Struchkov Mark 2024-06-17 18:57:16 +03:00
parent 110d7318c2
commit d26d6d4fc7
No known key found for this signature in database
GPG Key ID: A3F0AC3F0FA52F3C
5 changed files with 52 additions and 32 deletions

View File

@ -24,24 +24,24 @@
"unresolvedLinks": false,
"recentFilesStore": [
{
"filepath": "_inbox/Принцип локальности.md",
"timestamp": 1718639370931
"filepath": "_inbox/2024-06-17 1718639812.md",
"timestamp": 1718639813049
},
{
"filepath": "_inbox/Кэширование.md",
"timestamp": 1718639363870
"timestamp": 1718639716918
},
{
"filepath": "_inbox/Redis.md",
"timestamp": 1718639336820
"filepath": "_inbox/Принцип локальности.md",
"timestamp": 1718639715482
},
{
"filepath": "wiki/zero/00 HighLoad.md",
"timestamp": 1718638801082
"filepath": "_inbox/Least Recently Used.md",
"timestamp": 1718639706047
},
{
"filepath": "knowledge/human/Стресс.md",
"timestamp": 1718638580710
"filepath": "_inbox/Memcached.md",
"timestamp": 1718639697873
}
],
"starredFileStore": [],

View File

@ -1,12 +1,28 @@
{
"recentFiles": [
{
"basename": "Most Recently Used",
"path": "_inbox/Most Recently Used.md"
},
{
"basename": "Кэширование",
"path": "_inbox/Кэширование.md"
},
{
"basename": "Принцип локальности",
"path": "_inbox/Принцип локальности.md"
},
{
"basename": "Кэширование",
"path": "_inbox/Кэширование.md"
"basename": "Least Recently Used",
"path": "_inbox/Least Recently Used.md"
},
{
"basename": "Memcached",
"path": "_inbox/Memcached.md"
},
{
"basename": "Generational Collection",
"path": "knowledge/dev/java/gc/Generational Collection.md"
},
{
"basename": "Redis",
@ -136,10 +152,6 @@
"basename": "Обучающий курс от HighLoad конференции 2024",
"path": "source/курсы/_toc/Обучающий курс от HighLoad конференции 2024.md"
},
{
"basename": "Memcached",
"path": "_inbox/Memcached.md"
},
{
"basename": "00 Nginx",
"path": "wiki/zero/00 Nginx.md"
@ -187,18 +199,6 @@
{
"basename": "Без названия",
"path": "Без названия.md"
},
{
"basename": "00 MySQL",
"path": "wiki/zero/00 MySQL.md"
},
{
"basename": "00 Linux",
"path": "wiki/zero/00 Linux.md"
},
{
"basename": "Ударение",
"path": "_inbox/Ударение.md"
}
],
"omittedPaths": [],

View File

@ -8,6 +8,7 @@ date:
zero-link:
- "[[00 Разработка]]"
parents:
- "[[Кэширование]]"
linked:
---
LRU (Least Recently Used) — это алгоритм управления кэш-памятью, который выбирает для удаления тот элемент, который был использован дольше всего. Этот алгоритм часто используется в системах, где ограничены ресурсы памяти, и необходимо эффективно управлять кэшированием данных.

View File

@ -0,0 +1,11 @@
---
aliases:
- MRU
tags:
- зрелость/🌱
date:
- - 2024-06-17
zero-link:
parents:
linked:
---

View File

@ -23,9 +23,7 @@ linked:
- «**Не хотелось бы потерять**». Здесь можно упомянуть счетчики посетителей сайта, просмотров ресурсов и т.п. Хоть и восстановить эти значения иногда напрямую невозможно, но значения этих ключей имеют ограниченный по времени смысл: через несколько минут их значение уже неактуально, и будет рассчитано заново.
- «**Совсем не должны терять**». Кэш удобен для хранения сессий пользователей. Однако содержимое сессий не хотелось бы терять никогда иначе пользователей на сайте будет «разлогинивать». Как попытаться избежать? Можно кластеризовать систему кэширования, так вероятность потери снижается.
Инвалидация:
- По истечению срока жизни - TTL
- Принудительный вызов команды инвалидации
## Ключ кэширования
Ключ кэширования должен обладать следующими свойствами:
- При изменении параметров выборки, которую мы кэшируем, ключ кэширования должен изменяться (чтобы с новыми параметрами мы не «попали» в старый кэш).
@ -45,3 +43,13 @@ $key = md5(serialize($options))
Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари. При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей.
Первый вариант не подходит. Некоторые чуствительные данные нужно инвалидировать их сразу при изменении. Тут может помочь тегирование ключей.
Инвалидация:
- По истечению срока жизни - TTL
- Принудительный вызов команды инвалидации
- Алгоритмы вытеснения
Алгоритмы вытеснения:
- Алгоритм Белади. Несуществующий идеальный алгоритм. Храним только нужную информацию, не нужную не храним.
- [Least Recently Used](Least%20Recently%20Used.md)
- [[MRU]]