vault backup: 2024-06-18 08:34:14
This commit is contained in:
parent
fc6b020e79
commit
f7c3a59695
16
.obsidian/plugins/home-tab/data.json
vendored
16
.obsidian/plugins/home-tab/data.json
vendored
@ -23,6 +23,14 @@
|
||||
"markdownOnly": false,
|
||||
"unresolvedLinks": false,
|
||||
"recentFilesStore": [
|
||||
{
|
||||
"filepath": "_inbox/Кэширование.md",
|
||||
"timestamp": 1718688838197
|
||||
},
|
||||
{
|
||||
"filepath": "Инвалидация кэша.md",
|
||||
"timestamp": 1718688811143
|
||||
},
|
||||
{
|
||||
"filepath": "_inbox/Старт с холодным кэшом.md",
|
||||
"timestamp": 1718688297229
|
||||
@ -31,17 +39,9 @@
|
||||
"filepath": "home/Вычеты/Вычет 2024.md",
|
||||
"timestamp": 1718688293724
|
||||
},
|
||||
{
|
||||
"filepath": "_inbox/Кэширование.md",
|
||||
"timestamp": 1718688217945
|
||||
},
|
||||
{
|
||||
"filepath": "_inbox/Перестройка кэша.md",
|
||||
"timestamp": 1718688112432
|
||||
},
|
||||
{
|
||||
"filepath": "Home.md",
|
||||
"timestamp": 1718688013137
|
||||
}
|
||||
],
|
||||
"bookmarkedFileStore": [],
|
||||
|
@ -1,5 +1,13 @@
|
||||
{
|
||||
"recentFiles": [
|
||||
{
|
||||
"basename": "Кэширование",
|
||||
"path": "_inbox/Кэширование.md"
|
||||
},
|
||||
{
|
||||
"basename": "Инвалидация кэша",
|
||||
"path": "Инвалидация кэша.md"
|
||||
},
|
||||
{
|
||||
"basename": "Старт с холодным кэшом",
|
||||
"path": "_inbox/Старт с холодным кэшом.md"
|
||||
@ -8,10 +16,6 @@
|
||||
"basename": "Вычет 2024",
|
||||
"path": "home/Вычеты/Вычет 2024.md"
|
||||
},
|
||||
{
|
||||
"basename": "Кэширование",
|
||||
"path": "_inbox/Кэширование.md"
|
||||
},
|
||||
{
|
||||
"basename": "Перестройка кэша",
|
||||
"path": "_inbox/Перестройка кэша.md"
|
||||
@ -195,10 +199,6 @@
|
||||
{
|
||||
"basename": "00 PostgreSQL",
|
||||
"path": "wiki/zero/00 PostgreSQL.md"
|
||||
},
|
||||
{
|
||||
"basename": "PgBouncer",
|
||||
"path": "_inbox/PgBouncer.md"
|
||||
}
|
||||
],
|
||||
"omittedPaths": [],
|
||||
|
13
Cache miss.md
Normal file
13
Cache miss.md
Normal file
@ -0,0 +1,13 @@
|
||||
## Cache miss
|
||||
По формуле можно расчитать как часто мы будем промахиваться мимо кэша
|
||||
|
||||
AverageTime = CacheAccessTime + DbAccessTime \* CacheMissRate
|
||||
- AverageTime - среднее время жизни кэша
|
||||
- CacheAccessTime - время доступа к кэшу
|
||||
- DbAccessTime - время доступа к БД
|
||||
- CacheMissRate - количество промахов мимо кэша
|
||||
|
||||
Пусть
|
||||
- DbAccessTime = 100ms
|
||||
- CacheAccessTime = 20ms
|
||||
- Тогда при CacheMissRate > 0.8 - кэш вреден.
|
@ -50,38 +50,8 @@ $key = md5(serialize($options))
|
||||
|
||||
Такой ключ удовлетворяет первому условию% при изменении `$options` будет обязательно изменен `$key`, но и второе условие будет соблюдаться, если мы будем все типы данных в $options использовать «канонически», т.е. не допускать строки `"1"` вместо числа `1`. Функция `md5` используется для «сжатия» данных.
|
||||
|
||||
## Инвалидация
|
||||
Если мы закэшировали какие-то данные от backend’а, например, выборку из БД, рано или поздно исходные данные изменяются, и кэш перестает быть валидным. Причем очень желательно, чтобы кэш сбрасывался сразу же за изменением.
|
||||
|
||||
Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается 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)
|
||||
## Cache miss
|
||||
По формуле можно расчитать как часто мы будем промахиваться мимо кэша
|
||||
|
||||
AverageTime = CacheAccessTime + DbAccessTime \* CacheMissRate
|
||||
- AverageTime - среднее время жизни кэша
|
||||
- CacheAccessTime - время доступа к кэшу
|
||||
- DbAccessTime - время доступа к БД
|
||||
- CacheMissRate - количество промахов мимо кэша
|
||||
|
||||
Пусть
|
||||
- DbAccessTime = 100ms
|
||||
- CacheAccessTime = 20ms
|
||||
- Тогда при CacheMissRate > 0.8 - кэш вреден.
|
||||
## Инвалидация кэша
|
||||
![Инвалидация кэша](Инвалидация%20кэша.md)
|
||||
[Cache miss](Cache%20miss.md)
|
||||
## Дополнительные материалы
|
||||
- [Старт с холодным кэшом](Старт%20с%20холодным%20кэшом.md)
|
34
Инвалидация кэша.md
Normal file
34
Инвалидация кэша.md
Normal file
@ -0,0 +1,34 @@
|
||||
---
|
||||
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)
|
Loading…
Reference in New Issue
Block a user