vault backup: 2024-06-18 08:39:14

This commit is contained in:
2024-06-18 08:39:14 +03:00
parent f7c3a59695
commit addea6e43e
5 changed files with 36 additions and 21 deletions

View File

@@ -24,12 +24,16 @@
"unresolvedLinks": false, "unresolvedLinks": false,
"recentFilesStore": [ "recentFilesStore": [
{ {
"filepath": "_inbox/Кэширование.md", "filepath": "Инвалидация кэша.md",
"timestamp": 1718688838197 "timestamp": 1718688902451
}, },
{ {
"filepath": "Инвалидация кэша.md", "filepath": "_inbox/Кэширование.md",
"timestamp": 1718688811143 "timestamp": 1718688898521
},
{
"filepath": "Cache miss.md",
"timestamp": 1718688870602
}, },
{ {
"filepath": "_inbox/Старт с холодным кэшом.md", "filepath": "_inbox/Старт с холодным кэшом.md",
@@ -38,10 +42,6 @@
{ {
"filepath": "home/Вычеты/Вычет 2024.md", "filepath": "home/Вычеты/Вычет 2024.md",
"timestamp": 1718688293724 "timestamp": 1718688293724
},
{
"filepath": "_inbox/Перестройка кэша.md",
"timestamp": 1718688112432
} }
], ],
"bookmarkedFileStore": [], "bookmarkedFileStore": [],

View File

@@ -1,12 +1,16 @@
{ {
"recentFiles": [ "recentFiles": [
{
"basename": "Инвалидация кэша",
"path": "Инвалидация кэша.md"
},
{ {
"basename": "Кэширование", "basename": "Кэширование",
"path": "_inbox/Кэширование.md" "path": "_inbox/Кэширование.md"
}, },
{ {
"basename": "Инвалидация кэша", "basename": "Cache miss",
"path": "Инвалидация кэша.md" "path": "Cache miss.md"
}, },
{ {
"basename": "Старт с холодным кэшом", "basename": "Старт с холодным кэшом",
@@ -195,10 +199,6 @@
{ {
"basename": "Составные индексы в PostgreSQL", "basename": "Составные индексы в PostgreSQL",
"path": "_inbox/Составные индексы в PostgreSQL.md" "path": "_inbox/Составные индексы в PostgreSQL.md"
},
{
"basename": "00 PostgreSQL",
"path": "wiki/zero/00 PostgreSQL.md"
} }
], ],
"omittedPaths": [], "omittedPaths": [],

View File

@@ -1,7 +1,20 @@
## Cache miss ---
aliases:
tags:
- зрелость/🌱
date:
- - 2024-06-18
zero-link:
- "[[00 HighLoad]]"
parents:
- "[[Кэширование]]"
linked:
---
По формуле можно расчитать как часто мы будем промахиваться мимо кэша По формуле можно расчитать как часто мы будем промахиваться мимо кэша
AverageTime = CacheAccessTime + DbAccessTime \* CacheMissRate ```
AverageTime = CacheAccessTime + DbAccessTime * CacheMissRate
```
- AverageTime - среднее время жизни кэша - AverageTime - среднее время жизни кэша
- CacheAccessTime - время доступа к кэшу - CacheAccessTime - время доступа к кэшу
- DbAccessTime - время доступа к БД - DbAccessTime - время доступа к БД

View File

@@ -52,6 +52,8 @@ $key = md5(serialize($options))
## Инвалидация кэша ## Инвалидация кэша
![Инвалидация кэша](Инвалидация%20кэша.md) ![Инвалидация кэша](Инвалидация%20кэша.md)
[Cache miss](Cache%20miss.md)
## Cache miss
![Cache miss](Cache%20miss.md)
## Дополнительные материалы ## Дополнительные материалы
- [Старт с холодным кэшом](Старт%20с%20холодным%20кэшом.md) - [Старт с холодным кэшом](Старт%20с%20холодным%20кэшом.md)

View File

@@ -10,7 +10,6 @@ parents:
- "[[Кэширование]]" - "[[Кэширование]]"
linked: linked:
--- ---
Если мы закэшировали какие-то данные от backendа, например, выборку из БД, рано или поздно исходные данные изменяются, и кэш перестает быть валидным. Причем очень желательно, чтобы кэш сбрасывался сразу же за изменением. Если мы закэшировали какие-то данные от backendа, например, выборку из БД, рано или поздно исходные данные изменяются, и кэш перестает быть валидным. Причем очень желательно, чтобы кэш сбрасывался сразу же за изменением.
Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари. При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей. Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари. При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей.
@@ -18,9 +17,10 @@ linked:
Первый вариант не подходит. Некоторые чуствительные данные нужно инвалидировать их сразу при изменении. Тут может помочь тегирование ключей. Первый вариант не подходит. Некоторые чуствительные данные нужно инвалидировать их сразу при изменении. Тут может помочь тегирование ключей.
**Способы инвалидации:** **Способы инвалидации:**
- По истечению срока жизни - TTL. - Задать срок жизни - TTL.
- Самый простой способ. - Самая простая реализация.
- При малом TTL можно - При малом TTL будет высокий [Cache miss](Cache%20miss.md)
- При большом TTL данные могут быть не консистентны
- Принудительный вызов команды инвалидации. - Принудительный вызов команды инвалидации.
- Алгоритмы вытеснения - Алгоритмы вытеснения