Кэширование
All checks were successful
continuous-integration/drone/push Build is passing

This commit is contained in:
Struchkov Mark 2024-09-11 21:28:43 +03:00
parent 6376256d7e
commit d5e6b54a58
No known key found for this signature in database
GPG Key ID: A3F0AC3F0FA52F3C
28 changed files with 790 additions and 0 deletions

View File

@ -0,0 +1,32 @@
---
aliases:
tags:
- maturity/🌱
date:
- - 2024-06-17
zero-link:
- "[[../../meta/zero/00 Алгоритм|00 Алгоритм]]"
parents:
- "[[Алгоритмы вытеснения]]"
linked:
---
Объединяет преимущества: [Last Frequently Used](Last%20Frequently%20Used.md) и [Least Recently Used](Least%20Recently%20Used.md).
Принцип работы:
- Сохраняет два списка: недавно используемые элементы и давно не используемые
- Может динамически менять размер этих списков
***
## Мета информация
**Область**:: [[../../meta/zero/00 Алгоритм|00 Алгоритм]]
**Родитель**:: [[Алгоритмы вытеснения]]
**Источник**::
**Автор**::
**Создана**:: [[2024-06-17]]
### Дополнительные материалы
-
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,30 @@
---
aliases:
- LFU
tags:
- maturity/🌱
date:
- - 2024-06-17
zero-link:
- "[[../../meta/zero/00 Алгоритм|00 Алгоритм]]"
parents:
- "[[Алгоритмы вытеснения]]"
linked:
- "[[Most Recently Used]]"
---
Наиболее редко используемые данные вытесняются.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Алгоритм|00 Алгоритм]]
**Родитель**:: [[Алгоритмы вытеснения]]
**Источник**::
**Автор**::
**Создана**:: [[2024-06-17]]
### Дополнительные материалы
- [[Most Recently Used]]
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,49 @@
---
aliases:
- LRU
tags:
- maturity/🌱
date:
- - 2024-05-24
zero-link:
- "[[../../meta/zero/00 Алгоритм|00 Алгоритм]]"
parents:
- "[[Алгоритмы вытеснения]]"
linked:
- "[[Most Recently Used]]"
- "[[Псевдо-LRU]]"
---
Least Recently Used (LRU) — это алгоритм управления кэш-памятью, который выбирает для удаления тот элемент, который давно не использовался. Этот алгоритм часто используется в системах, где ограничены ресурсы памяти, и необходимо эффективно управлять кэшированием данных.
**Принцип работы:**
1. **Отслеживание использования**: Каждый элемент в кэше имеет метку времени или счетчик, который обновляется каждый раз, когда элемент используется.
2. **Удаление устаревших элементов**: Когда необходимо освободить место в кэше для нового элемента, удаляется элемент с наименьшим значением метки времени или счетчика, то есть наименее недавно использованный элемент.
**Преимущества**:
- Эффективное управление памятью.
- Простота реализации и понятная логика работы.
**Недостатки**:
- Высокие накладные расходы на обновление меток времени или счетчиков. Поэтому чаще всего используют [Псевдо-LRU](Псевдо-LRU.md).
- Возможность неэффективной работы в некоторых специфических случаях, когда часто используемые элементы могут вытесняться из кэша.
**Примеры использования:**
- [[../architecture/Кэширование|Кэширование]] страниц в веб-браузерах.
- Управление оперативной памятью в [[../../../../knowledge/dev/pc/Операционная система|операционных системах]].
- Кэширование данных в базах данных и других системах хранения.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Алгоритм|00 Алгоритм]]
**Родитель**:: [[Алгоритмы вытеснения]]
**Источник**::
**Автор**::
**Создана**:: [[2024-05-24]]
### Дополнительные материалы
- [[Most Recently Used]]
- [[Псевдо-LRU]]
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,38 @@
---
aliases:
- MRU
tags:
- maturity/🌱
date:
- - 2024-06-17
zero-link:
- "[[../../meta/zero/00 Алгоритм|00 Алгоритм]]"
parents:
- "[[Алгоритмы вытеснения]]"
linked:
- "[[Least Recently Used]]"
---
Наименее редко используемые данные вытесняются.
**Принцип работы:**
**Преимущества**:
**Недостатки**:
**Примеры использования:**
***
## Мета информация
**Область**:: [[../../meta/zero/00 Алгоритм|00 Алгоритм]]
**Родитель**:: [[Алгоритмы вытеснения]]
**Источник**::
**Автор**::
**Создана**:: [[2024-06-17]]
### Дополнительные материалы
- [[Least Recently Used]]
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,26 @@
---
aliases:
tags:
- maturity/🌱
date: 2024-09-11
zero-link:
- "[[../../meta/zero/00 Алгоритм|00 Алгоритм]]"
parents:
- "[[../architecture/highload/Инвалидация кэша]]"
linked:
---
- Алгоритм Белади. Несуществующий идеальный алгоритм. Храним только нужную информацию, не нужную не храним.
- [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)
***
## Мета информация
**Область**:: [[../../meta/zero/00 Алгоритм|00 Алгоритм]]
**Родитель**:: [[../architecture/highload/Инвалидация кэша]]
**Источник**::
**Создана**:: [[2024-09-11]]
**Автор**::
### Дополнительные материалы
-

View File

@ -0,0 +1,35 @@
---
aliases:
tags:
- maturity/🌱
date:
- - 2024-06-18
zero-link:
- "[[../../meta/zero/00 Алгоритм|00 Алгоритм]]"
parents:
- "[[Алгоритмы вытеснения]]"
linked:
- "[[Least Recently Used]]"
---
В отличие от [LRU](Least%20Recently%20Used.md) уменьшает накладные расчеты на обновление меток времени и счетчиков.
**Принцип работы:**
- У каждого ключа есть какой-то бит данных
- В цикле бегут потоки и снимают бит этим ключам
- Когда данные по ключу читаются бит помечается прочитанным
- Если нам нужно вытеснить информацию из кэша, то мы идем по ключам в поиске ключей со снятым битиком.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Алгоритм|00 Алгоритм]]
**Родитель**:: [[Алгоритмы вытеснения]]
**Источник**::
**Автор**::
**Создана**:: [[2024-06-18]]
### Дополнительные материалы
- [[Least Recently Used]]
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,44 @@
---
aliases:
- задержка
- время отклика
tags:
- maturity/🌱
date:
- - 2024-03-12
zero-link:
- "[[../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
linked:
---
Latency - это время, необходимое для выполнения какой-либо операции или передачи данных от одной точки к другой. В более широком смысле, это период времени между началом действия и моментом, когда его результаты становятся заметны.
**Что влияет?**
- **Расстояние**: Физическое расстояние между отправителем и получателем данных напрямую влияет на время передачи сигнала, особенно при больших расстояниях.
- **Скорость передачи данных среды**: Скорость, с которой данные передаются через физическую среду (например, медные кабели, оптоволокно, беспроводные каналы), также влияет на задержку.
- **Пропускная способность сети**: Высокая загруженность сети и ограниченная пропускная способность могут приводить к задержкам из-за ожидания доступа к сетевым ресурсам.
- **Обработка данных**: Время, необходимое для обработки данных устройствами, такими как маршрутизаторы, коммутаторы и серверы, также вносит свой вклад в общую задержку.
- **Количество прыжков (хопов) в сети**: Количество устройств (например, маршрутизаторов и коммутаторов), через которые данные должны пройти от источника к пункту назначения, увеличивает общее время задержки.
- **Эффективность используемых протоколов**. Например, дополнительные шаги рукопожатия создают задержку
**Что поможет уменьшить значение:**
- **Оптимизация производительности сервера**: Улучшение аппаратных характеристик сервера, таких как процессор, оперативная память и системы хранения, может сократить время обработки запросов.
- **Использование кэширования**: [[Кэширование]] часто запрашиваемых данных на сервере или ближе к клиенту может существенно сократить время доступа к этим данным, поскольку избавляет от необходимости каждый раз обращаться к основному источнику данных.
- **Оптимизация базы данных**: Индексация, оптимизация запросов и структур данных, а также выбор подходящего типа базы данных могут снизить время доступа к данным
- **Минимизация расстояния**: Размещение серверов ближе к конечным пользователям или использование сети доставки контента ([CDN](highload/Content%20Delivery%20Network.md)) может снизить физическую задержку, связанную с расстоянием, которое должны преодолеть данные.
- **Сокращение объема передаваемых данных**: Минимизация размера данных, передаваемых между клиентом и сервером (например, сжатие данных и изображений), может уменьшить время их передачи.
***
## Мета информация
**Область**:: [[../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**::
**Источник**::
**Автор**::
**Создана**:: [[2024-03-12]]
### Дополнительные материалы
- [[Throughput]]
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,49 @@
---
aliases:
- пропускная способность
tags:
- maturity/🌱
date:
- - 2024-03-12
zero-link:
- "[[../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
linked: []
---
Throughput - пропускная способность системы, то есть количество работы, которое система или процесс может выполнить в единицу времени.
**В чем можно измерять:**
- Для web-систем
- Количество запросов в единицу времени
- Requests per seconds (RPS)
- Request per minute (RPM)
- Количество данных в единицу времени
- Packets per seconds (PPS)
- Мегабит в секунду (MB/s)
- Количество одновременно обслуживаемых соединений
- Simultaneous connections
- Cuncurrency
- Для баз данных
- транзакциях в секунду (т/с)
- операциях в секунду (оп/с)
Что влияет на значение Throughput:
- Аппаратные ресурсы
- **Сетевая инфраструктура**: В сетевых системах скорость и пропускная способность сети, задержки, [потеря пакетов](Потеря%20пакетов.md), а также эффективность протоколов передачи данных играют ключевую роль в определении общей пропускной способности системы.
- **Масштабирование**: Способность системы к [горизонтальному](Горизонтальное%20масштабирование.md) и [вертикальному масштабированию](Вертикальное%20масштабирование.md) также влияет на Throughput. Горизонтальное масштабирование путем добавления дополнительных узлов может увеличить пропускную способность, но также добавляет накладные расходы на синхронизацию и управление.
- **Конфигурация системы**: Настройки и конфигурация системы, включая размеры пула соединений, размеры буферов и кэшей, могут влиять на производительность и пропускную способность.
***
## Мета информация
**Область**:: [[../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**::
**Источник**::
**Автор**::
**Создана**:: [[2024-03-12]]
### Дополнительные материалы
- [[Latency]]
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,24 @@
---
aliases:
tags:
- maturity/🌱
date:
- - 2024-06-18
zero-link:
- "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
- "[[../Кэширование|Кэширование]]"
linked:
- "[[Оценка эффективности кэша|Оценка эффективности кэша]]"
---
CacheMissRate показывает, насколько часто кэш не справляется с задачей хранения нужных данных и приходится обращаться к базе данных. Обычно рассчитывается как отношение количества промахов мимо кэша к общему количеству запросов на чтение данных. Формула для CacheMissRate выглядит так:
```
CacheMissRate= Количество промахов / Количество запросов.
```
Где:
**Количество промахов** — это число случаев, когда данные не были найдены в кэше и потребовался доступ к базе данных.
**Общее количество запросов** — это общее количество запросов на чтение данных, которые могут быть обслужены кэшем.
[[Оценка эффективности кэша]]

View File

@ -0,0 +1,35 @@
---
aliases:
- CDN
tags:
- maturity/🌱
date:
- - 2024-01-11
zero-link:
- "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
- "[[../Кэширование|Кэширование]]"
linked:
---
Распределенная географическая сеть кэширующих серверов по всему миру, которая позволяет доставлять контент до пользователей быстрее за счет более близкого расположения сервера к клиенту.
Бывают push и pull реализации. В push CDN мы должны сами отправить данные, которые будут доступны из cdn. В pull модели CDN сама сходит на сервер за нужными данными.
**Плюсы:**
- Географически распределенный кэш
- Уменьшает количество запросов на сервера
***
## Мета информация
**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**:: [[../Кэширование|Кэширование]]
**Источник**::
**Автор**::
**Создана**:: [[2024-01-11]]
### Дополнительные материалы
-
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,45 @@
---
aliases:
- инвалидации кэша
tags:
- maturity/🌱
date:
- - 2024-06-18
zero-link:
- "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
- "[[../Кэширование|Кэширование]]"
linked:
---
Если мы закэшировали какие-то данные, например, выборку из БД, рано или поздно исходные данные изменяются, и кэш перестает быть валидным. Причем очень желательно, чтобы кэш сбрасывался сразу же за изменением.
**Способы инвалидации:**
- Задать срок жизни - TTL.
- Самая простая реализация.
- При малом TTL будет высокий [CacheMissRate](CacheMissRate.md)
- При большом TTL данные могут быть не консистентны
- Инвалидация по событию
- Удаляем старые данные при изменении в базе или по событию от кафки.
- Опасно из-за риска мгновенной инвалидации и сопутствующей [[Перестройка кэша|перестройки кэша]]
- Использование [[../../algorithm/Алгоритмы вытеснения|алгоритмов вытеснения]]
Дополнительно для работы со статическими файлами можно отменить [[../../../../../_inbox/Fingerprint|Fingerprint]].
Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари. При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей. В оценке эффективности кэша поможет метрика [[CacheMissRate]].
Некоторые чувствительные данные нужно инвалидировать сразу при изменении. Тут может помочь тегирование ключей.
***
## Мета информация
**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**:: [[../Кэширование|Кэширование]]
**Источник**::
**Автор**::
**Создана**:: [[2024-06-18]]
### Дополнительные материалы
-
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,74 @@
---
aliases:
tags:
- maturity/🌱
date:
- - 2024-04-07
zero-link:
- "[[00 Nginx]]"
parents:
- "[[../Кэширование|Кэширование]]"
linked:
- "[[Кэширование статики в Nginx]]"
---
Если какие-то запросы не часто меняются, то можно закэшировать их на стороне сервера. Тогда Nginx один раз получит результат запроса от вашего приложения, а дальше будет отдавать их другим клиентам.
Перед настройками, нам нужно создать директорию, в которой будут хранится данные кэша:
```shell
sudo mkdir -p /var/nginx/cache
```
Чтобы включить кэширование, нужно прописать несколько директив в основной конфигурации `nginx.conf`.
```nginx
http {
proxy_cache_path /var/nginx/cache levels=1:2 keys_zone=nginxcash:60m max_size=256m inactive=24h;
proxy_cache_key "$scheme$request_method$host$request_uri";
proxy_cache_methods GET HEAD;
proxy_cache_min_uses 2;
}
```
`proxy_cache_path` указывает путь в файловой системе.
Не кэшируйте HTTP-ответы при первом обращении. Используйте `proxy_cache_min_uses 2`, чтобы кэшировать только те элементы, к которым обращались более одного раза. Таким образом, вы уменьшите нагрузку прокси-кэша на запись и предотвратите заполнение кэша содержимым, к которому редко обращаются.
Ключ кэширования Nginx по умолчанию не очень хорошо работает с сайтами с несколькими поддоменами. Вы можете настроить ключ кэширования, задав proxy_cache_key. В своей конфигурации я использую вот такой ключ: `proxy_cache_key $scheme$host$uri$is_args$args;`
## Переносим кэш Nginx в RAM
Можно значительно ускорить кэш, если смонтировать его не в файловую систему а в RAM.
Для этого также создаем папку для кэша, можно использовать ту же, но ее нужно очистить от папок. Далее монтируем созданный каталог в RAM с помощью команды [tmpfs](https://wiki.archlinux.org/index.php/Tmpfs), выделяя 256 мегабайт под кэш:
```shell
sudo mount -t tmpfs -o size=256M tmpfs /var/nginx/cache
```
Если вам понадобиться отключить RAM-кэш, просто выполните команду:
```shell
sudo umount /var/nginx/cache
```
Чтобы автоматически пересоздать каталог к'ша в RAM после перезагрузки сервера, нам нужно обновить файл `/etc/fstab`. Добавьте в него следующую строку:
```txt
tmpfs /var/nginx/cache tmpfs defaults,size=256M 0 0
```
***
## Мета информация
**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**:: [[../Кэширование|Кэширование]]
**Источник**::
**Автор**::
**Создана**:: [[2024-04-07]]
### Дополнительные материалы
- [Оптимизация NGINX](https://struchkov.dev/blog/ru/nginx-optimization/)
- [Nginx cache: всё новое — хорошо забытое старое / Хабр](https://habr.com/ru/post/428127/)
- [[../../../../../_inbox/Кэширование статики в Nginx|Кэширование статики в Nginx]]
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,50 @@
---
aliases:
tags:
- maturity/🌱
date:
- - 2024-06-17
zero-link:
- "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
- "[[../Кэширование|Кэширование]]"
linked:
---
Обычно кэшируются только GET запросы, так как они должны быть [[../Идемпотентность|идемпотентны]].
Заголовки для кэширования:
- ETAG. Тег, который позволяет указать версию файла. Можно использовать MD5.
- If-Modified-Since. Дата изменения файла.
- Cache-Control
- public - Сохранять может не только браузер, но и промежуточные узлы
- private - Сохранять может только браузер клиента
- no-store - не кэшируем. ==не уверен что правильно записал==
- no-cache - Сохранять только в браузере, не сохранять на промежуточных серверах. ==не уверен что правильно записал==
- max-age - Сколько нужно хранить файл в памяти
- LocalStorage. Можно через JS складывать данные.
Статический контент - это содержимое сайта, которое остается неизменным продолжительное время на всех страницах. Например, это такие файлы, как картинки, CSS и JS файлы.
Так как эти файлы редко изменяются, то можно сохранять их в кэше браузера пользователя. Вместо того, чтобы обращаться к серверу каждый раз, браузер будет использовать свою локальную копию этих файлов.
![](../../../meta/files/images/Pasted%20image%2020240619083856.png)
Инвалидация:
- Самый простой вариант указывать версию в GET параметрах.
- Для статики можно использовать [[Fingerprint]]
***
## Мета информация
**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**::
**Источник**::
**Автор**::
**Создана**:: [[2024-06-17]]
### Дополнительные материалы
- [[Кэширование статики в Nginx]]
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,38 @@
---
aliases:
tags:
- maturity/🌱
date: 2024-09-11
zero-link:
- "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
- "[[../Кэширование|Кэширование]]"
linked:
- "[[CacheMissRate|CacheMissRate]]"
---
По формуле можно рассчитать среднее время доступа к данным.
```
AverageTime = CacheAccessTime + DbAccessTime * CacheMissRate
```
Где:
- AverageTime - среднее время жизни кэша
- CacheAccessTime - время доступа к кэшу
- DbAccessTime - время доступа к БД
- [[CacheMissRate|CacheMissRate]] - количество промахов мимо кэша. От 0 до 1.
Например, пусть
- DbAccessTime = 100ms
- CacheAccessTime = 20ms
- Тогда при [[CacheMissRate|CacheMissRate]] > 0.8 - кэш вреден.
***
## Мета информация
**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**:: [[../Кэширование|Кэширование]]
**Источник**::
**Создана**:: [[2024-09-11]]
**Автор**::
### Дополнительные материалы
- [[CacheMissRate|CacheMissRate]]

View File

@ -0,0 +1,39 @@
---
aliases:
- thundering herd
tags:
- maturity/🌱
date:
- - 2024-06-18
zero-link:
- "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
- "[[../Кэширование|Кэширование]]"
linked:
---
Представим, что у нас 3 реплики сервиса, которые выполняют какие-то вычисления раз в 30 секунд, а в вычислениях используется кэшированные значения. При [[Инвалидация кэша|инвалидации кэша]] может сложиться ситуация при которой все 3 реплики начнут наперегонки обновлять значение в кэше. Это приводит как минимум к лишней нагрузке на базу данных, а как максимум к отказу в обслуживании.
Решить эту проблему можно с использованием [[../../../../../_inbox/Блокировка|блокировок]]:
- Получаем доступ к кэшу, его срок жизни истёк. Пытаемся заблокироваться по ключу.
- Не удалось получить блокировку
- Ждём снятия [[../../../../../_inbox/Блокировка|блокировки]].
- Если не дождались, возвращаем старые данные кэша
- Если дождались, значит кто-то построил кэш за нас, выбираем значения ключа заново, возвращаем новые данные.
- Удалось получить блокировку
- Строим кэш самостоятельно
- Снимаем блокировку
***
## Мета информация
**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**:: [[../Кэширование|Кэширование]]
**Источник**::
**Автор**::
**Создана**::
### Дополнительные материалы
-
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,33 @@
---
aliases:
tags:
- maturity/🌱
date:
- - 2024-06-18
zero-link:
- "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
- "[[../Кэширование|Кэширование]]"
linked:
---
После аварии кэш, скорее всего будет [[Инвалидация кэша|инвалидирован]]. А в случае не персистентных хранилищ кэша не будет точно после отключения питания. Для некоторых систем подняться с не прогретым кэшом сложная задача.
Что может помочь:
- Заранее напишите скрипт прогрева кэшей
- Возвращайте нагрузку плавно
- Помните о том, что нагрузку стоит уметь держать без кэш
***
## Мета информация
**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**:: [[../Кэширование|Кэширование]]
**Источник**::
**Автор**::
**Создана**:: [[2024-06-18]]
### Дополнительные материалы
-
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,26 @@
---
aliases:
- идемпотентны
- идемпотентной
tags:
- maturity/🌱
date: 2024-09-11
zero-link:
- "[[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]]"
parents:
linked:
---
Идемпотентность — это свойство операции, при котором многократное выполнение этой операции с одинаковыми входными данными не изменяет результат после первого выполнения. Иными словами, независимо от того, сколько раз вы выполните операцию, итог будет одним и тем же.
Примером идемпотентной операции может быть запрос на установку значения, например, «установить цену товара в 100». Если отправить этот запрос несколько раз, цена останется 100, и результат не изменится. В противоположность этому, операция «увеличить цену на 10» не является идемпотентной, так как каждое выполнение увеличивает цену, и результат меняется.
Идемпотентность позволяет системе быть устойчивой к ошибкам и повторам — если запрос случайно повторится, это не приведет к нежелательным изменениям.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]]
**Родитель**::
**Источник**::
**Создана**:: [[2024-09-11]]
**Автор**::
### Дополнительные материалы
-

View File

@ -0,0 +1,20 @@
---
aliases:
tags:
- maturity/🌱
date:
- - 2024-06-17
zero-link:
- "[[../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
- "[[Кэширование]]"
linked:
---
Поход в базу данных может быть достаточно дорогим, в этом случае имеет смысл сохранять данные в кэш. Ускорить сложные запросы может кэширование: мы помещаем результат вычислений в некоторое хранилище (например, [Memcached](Memcached.md) или [Redis](Redis.md)), которое обладает отличными характеристиками по времени доступа к информации. Теперь вместо обращений к медленным, сложным и тяжелым backendам нам достаточно выполнить запрос к быстрому кэшу.
![](../../meta/files/images/Pasted%20image%2020240617184722.png)
Самые распространенные варианты хранения:
- Хранение в ОЗУ
- [Memcached](Memcached.md)
- [Redis](Redis.md)

View File

@ -0,0 +1,69 @@
---
aliases:
- кэш
tags:
- maturity/🌱
date:
- - 2024-05-24
zero-link:
- "[[../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
linked:
---
Для каждого ресурса критичной для пользователя является такая характеристика, как [[Latency|время отклика]] сервера. Увеличение времени отклика сервера приводит к оттоку посетителей. Следовательно, необходимо минимизировать [[Latency|время отклика]]: для этого необходимо уменьшать время, требуемое на формирование ответа пользователю, при этом для формирования ответа пользователю необходимо получить данные из каких-то внешних ресурсов ([Бэкенд](Бэкенд.md)).
> [!TIP] Работа без кэша
> Хорошая система должна уметь выдерживать нагрузку и без кэша. Задача кэша ускорить ответ, а не держать нагрузку.
==Системы используемые для кэширования обычно не являются надежными, так что не следует хранить только там какие-то важные данные.== Чаще всего кэш реализуется на основе хэш-таблиц и использует [принцип локальности](../fundamental/Принцип%20локальности.md).
Сами данные можно разделить на несколько категорий:
- **Можно потерять**. К этой категории относятся кэши выборок из базы данных. Потеря таких ключей не так страшна, потому что мы можем легко восстановить их значения, обратившись заново к backendу. Однако частые потери кэшей приводят к излишним обращениям к БД.
- **Не хотелось бы потерять**. Здесь можно упомянуть счетчики посетителей сайта, просмотров ресурсов и т.п. Хоть и восстановить эти значения иногда напрямую невозможно, но значения этих ключей имеют ограниченный по времени смысл: через несколько минут их значение уже неактуально, и будет рассчитано заново.
- **Совсем не должны терять**. Кэш удобен для хранения сессий пользователей. Однако содержимое сессий не хотелось бы терять никогда иначе пользователей на сайте будет «разлогинивать». Как попытаться избежать? Можно кластеризовать систему кэширования, так вероятность потери снижается.
## Уровни кэширования
![](../../meta/files/images/Pasted%20image%2020240617195054.png)
![](../../meta/files/images/Pasted%20image%2020240701115612.png)
Уровни кэширования:
- [Кэширование на стороне браузера](highload/Кэширование%20на%20стороне%20браузера.md)
- [Кэширование на стороне Nginx](highload/Кэширование%20на%20стороне%20Nginx.md)
- [Content Delivery Network](highload/Content%20Delivery%20Network.md)
- [Кэширование в приложении](Кэширование%20в%20приложении.md)
Виды кэширования:
- Сквозное. Все запросы проходят через кэш. [Схема](../../meta/files/images/Pasted%20image%2020240617194731.png).
- Кэширование на стороне сервиса. [Схема](../../meta/files/images/Pasted%20image%2020240617194759.png).
- Опережающее. Кладем данные в кэш заранее. [Схема](../../meta/files/images/Pasted%20image%2020240617194938.png).
## Ключ кэширования
Ключ кэширования должен обладать следующими свойствами:
- При изменении параметров выборки, которую мы кэшируем, ключ кэширования должен изменяться (чтобы с новыми параметрами мы не «попали» в старый кэш).
- По параметрам выборки ключ должен определяться однозначно, т.е. для одной и той же выборки ключ кэширования должен быть только один, иначе мы рискуем понизить эффективность процесса кэширования, создавая несколько кэшей для одной и той же выборки.
Можно использовать следующий вариант (пример для PHP): если существует некоторая точка в коде, через которую проходят все обращения к БД, а любое обращение полностью описывается (содержит все параметры запроса) в некоторой структуре `$options`, можно использовать следующий ключ:
```php
$key = md5(serialize($options))
```
Такой ключ удовлетворяет первому условию: при изменении `$options` будет обязательно изменен `$key`, но и второе условие будет соблюдаться, если мы будем все типы данных в $options использовать «канонически», т.е. не допускать строки `"1"` вместо числа `1`. Функция `md5` используется для «сжатия» данных.
Если мы закэшировали какие-то данные от backendа, например, выборку из БД, рано или поздно исходные данные изменяются, и кэш перестает быть валидным. Причем очень желательно, чтобы кэш сбрасывался сразу же за изменением. За это отвечает [[highload/Инвалидация кэша|Инвалидация кэша]]
***
## Мета информация
**Область**:: [[../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**::
**Источник**::
**Автор**::
**Создана**:: [[2024-05-24]]
### Дополнительные материалы
- [[highload/Оценка эффективности кэша|Оценка эффективности кэша]]
- [Старт с холодным кэшем](highload/Старт%20с%20холодным%20кэшем.md)
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

View File

@ -0,0 +1,33 @@
---
aliases:
- принципе локальности
tags:
- maturity/🌱
date:
- - 2024-05-24
zero-link:
- "[[../../meta/zero/00 Разработка|00 Разработка]]"
parents:
linked:
---
Программе свойственно в определенный промежуток времени работать с некоторым небольшим подмножеством данных из всего набора.
Наглядные примеры:
- Для чатов - последние сообщения
- Для новостей - последние новости
- Для сервиса такси - активные заказы
***
## Мета информация
**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
**Родитель**::
**Источник**::
**Автор**::
**Создана**:: [[2024-05-24]]
### Дополнительные материалы
-
### Дочерние заметки
```dataview
LIST
FROM [[]]
WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link)
```

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 873 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.2 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1002 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.6 MiB

View File

@ -5,4 +5,5 @@ parents:
- "[[00 Разработка]]"
title: Алгоритм
---
- [[../../dev/algorithm/Алгоритмы вытеснения|Алгоритмы вытеснения]]
- [Бинарный поиск на Java](../../dev/java/Бинарный%20поиск%20на%20Java.md)