diff --git a/dev/algorithm/Adaptive Replacement Cache.md b/dev/algorithm/Adaptive Replacement Cache.md
new file mode 100644
index 00000000..dc629e22
--- /dev/null
+++ b/dev/algorithm/Adaptive Replacement Cache.md	
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/algorithm/Last Frequently Used.md b/dev/algorithm/Last Frequently Used.md
new file mode 100644
index 00000000..18ef7c89
--- /dev/null
+++ b/dev/algorithm/Last Frequently Used.md	
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/algorithm/Least Recently Used.md b/dev/algorithm/Least Recently Used.md
new file mode 100644
index 00000000..80695786
--- /dev/null
+++ b/dev/algorithm/Least Recently Used.md	
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/algorithm/Most Recently Used.md b/dev/algorithm/Most Recently Used.md
new file mode 100644
index 00000000..0fd6c9cc
--- /dev/null
+++ b/dev/algorithm/Most Recently Used.md	
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/algorithm/Алгоритмы вытеснения.md b/dev/algorithm/Алгоритмы вытеснения.md
new file mode 100644
index 00000000..30e2d722
--- /dev/null
+++ b/dev/algorithm/Алгоритмы вытеснения.md	
@@ -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]]
+**Автор**:: 
+### Дополнительные материалы
+- 
\ No newline at end of file
diff --git a/dev/algorithm/Псевдо-LRU.md b/dev/algorithm/Псевдо-LRU.md
new file mode 100644
index 00000000..e27d3253
--- /dev/null
+++ b/dev/algorithm/Псевдо-LRU.md
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/architecture/Latency.md b/dev/architecture/Latency.md
new file mode 100644
index 00000000..3e959b3d
--- /dev/null
+++ b/dev/architecture/Latency.md
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/architecture/Throughput.md b/dev/architecture/Throughput.md
new file mode 100644
index 00000000..f039f65c
--- /dev/null
+++ b/dev/architecture/Throughput.md
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/architecture/highload/CacheMissRate.md b/dev/architecture/highload/CacheMissRate.md
new file mode 100644
index 00000000..5846b642
--- /dev/null
+++ b/dev/architecture/highload/CacheMissRate.md
@@ -0,0 +1,24 @@
+---
+aliases: 
+tags:
+  - maturity/🌱
+date:
+  - - 2024-06-18
+zero-link:
+  - "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
+parents:
+  - "[[../Кэширование|Кэширование]]"
+linked:
+  - "[[Оценка эффективности кэша|Оценка эффективности кэша]]"
+---
+CacheMissRate показывает, насколько часто кэш не справляется с задачей хранения нужных данных и приходится обращаться к базе данных. Обычно рассчитывается как отношение количества промахов мимо кэша к общему количеству запросов на чтение данных. Формула для CacheMissRate выглядит так:
+
+```
+CacheMissRate= Количество промахов / Количество запросов.
+```
+
+Где:
+• **Количество промахов** — это число случаев, когда данные не были найдены в кэше и потребовался доступ к базе данных.
+• **Общее количество запросов** — это общее количество запросов на чтение данных, которые могут быть обслужены кэшем.
+
+[[Оценка эффективности кэша]]
\ No newline at end of file
diff --git a/dev/architecture/highload/Content Delivery Network.md b/dev/architecture/highload/Content Delivery Network.md
new file mode 100644
index 00000000..6c6909c1
--- /dev/null
+++ b/dev/architecture/highload/Content Delivery Network.md	
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/architecture/highload/Инвалидация кэша.md b/dev/architecture/highload/Инвалидация кэша.md
new file mode 100644
index 00000000..d7c318a4
--- /dev/null
+++ b/dev/architecture/highload/Инвалидация кэша.md	
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/architecture/highload/Кэширование на стороне Nginx.md b/dev/architecture/highload/Кэширование на стороне Nginx.md
new file mode 100644
index 00000000..67a38b16
--- /dev/null
+++ b/dev/architecture/highload/Кэширование на стороне Nginx.md	
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/architecture/highload/Кэширование на стороне браузера.md b/dev/architecture/highload/Кэширование на стороне браузера.md
new file mode 100644
index 00000000..3481fb39
--- /dev/null
+++ b/dev/architecture/highload/Кэширование на стороне браузера.md	
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/architecture/highload/Оценка эффективности кэша.md b/dev/architecture/highload/Оценка эффективности кэша.md
new file mode 100644
index 00000000..353ac16b
--- /dev/null
+++ b/dev/architecture/highload/Оценка эффективности кэша.md	
@@ -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]]
\ No newline at end of file
diff --git a/dev/architecture/highload/Перестройка кэша.md b/dev/architecture/highload/Перестройка кэша.md
new file mode 100644
index 00000000..f1b32e18
--- /dev/null
+++ b/dev/architecture/highload/Перестройка кэша.md	
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/architecture/highload/Старт с холодным кэшем.md b/dev/architecture/highload/Старт с холодным кэшем.md
new file mode 100644
index 00000000..fd37da98
--- /dev/null
+++ b/dev/architecture/highload/Старт с холодным кэшем.md	
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/architecture/Идемпотентность.md b/dev/architecture/Идемпотентность.md
new file mode 100644
index 00000000..8d23540e
--- /dev/null
+++ b/dev/architecture/Идемпотентность.md
@@ -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]]
+**Автор**:: 
+### Дополнительные материалы
+- 
\ No newline at end of file
diff --git a/dev/architecture/Кэширование в приложении.md b/dev/architecture/Кэширование в приложении.md
new file mode 100644
index 00000000..43a7f36d
--- /dev/null
+++ b/dev/architecture/Кэширование в приложении.md	
@@ -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)
\ No newline at end of file
diff --git a/dev/architecture/Кэширование.md b/dev/architecture/Кэширование.md
new file mode 100644
index 00000000..21fb19cd
--- /dev/null
+++ b/dev/architecture/Кэширование.md
@@ -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)
+```
\ No newline at end of file
diff --git a/dev/fundamental/Принцип локальности.md b/dev/fundamental/Принцип локальности.md
new file mode 100644
index 00000000..7477a474
--- /dev/null
+++ b/dev/fundamental/Принцип локальности.md	
@@ -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)
+```
\ No newline at end of file
diff --git a/meta/files/images/Pasted image 20240617184722.png b/meta/files/images/Pasted image 20240617184722.png
new file mode 100644
index 00000000..90cd28a2
Binary files /dev/null and b/meta/files/images/Pasted image 20240617184722.png differ
diff --git a/meta/files/images/Pasted image 20240617194731.png b/meta/files/images/Pasted image 20240617194731.png
new file mode 100644
index 00000000..91eb6020
Binary files /dev/null and b/meta/files/images/Pasted image 20240617194731.png differ
diff --git a/meta/files/images/Pasted image 20240617194759.png b/meta/files/images/Pasted image 20240617194759.png
new file mode 100644
index 00000000..123e12c9
Binary files /dev/null and b/meta/files/images/Pasted image 20240617194759.png differ
diff --git a/meta/files/images/Pasted image 20240617194938.png b/meta/files/images/Pasted image 20240617194938.png
new file mode 100644
index 00000000..320c567a
Binary files /dev/null and b/meta/files/images/Pasted image 20240617194938.png differ
diff --git a/meta/files/images/Pasted image 20240617195054.png b/meta/files/images/Pasted image 20240617195054.png
new file mode 100644
index 00000000..8380151b
Binary files /dev/null and b/meta/files/images/Pasted image 20240617195054.png differ
diff --git a/meta/files/images/Pasted image 20240619083856.png b/meta/files/images/Pasted image 20240619083856.png
new file mode 100644
index 00000000..3d2e520b
Binary files /dev/null and b/meta/files/images/Pasted image 20240619083856.png differ
diff --git a/meta/files/images/Pasted image 20240701115612.png b/meta/files/images/Pasted image 20240701115612.png
new file mode 100644
index 00000000..720fce62
Binary files /dev/null and b/meta/files/images/Pasted image 20240701115612.png differ
diff --git a/meta/zero/00 Алгоритм.md b/meta/zero/00 Алгоритм.md
index 5a4ed38d..5b4448ad 100644
--- a/meta/zero/00 Алгоритм.md	
+++ b/meta/zero/00 Алгоритм.md	
@@ -5,4 +5,5 @@ parents:
   - "[[00 Разработка]]"
 title: Алгоритм
 ---
+- [[../../dev/algorithm/Алгоритмы вытеснения|Алгоритмы вытеснения]]
 - [Бинарный поиск на Java](../../dev/java/Бинарный%20поиск%20на%20Java.md)
\ No newline at end of file