872 changed files with 822 additions and 1663 deletions
--- a/.DS_Store
+++ b/.DS_Store
--- a/awareness/Медитация.md
+++ b/awareness/Медитация.md
@ -1,33 +0,0 @@
---
-tags:
-  - maturity/🌱
-date: "[[2023-09-20]]"
-aliases:
-  - медитация
-  - релаксация
-  - релакс
-  - медитацией
-  - медитацию
-  - медитации
---
-Медитация работает на физиологическом уровне: замедляет дыхание и частоту сердечных сокращений. [Замедляет](https://www.psychologytoday.com/blog/the-mysteries-love/201503/how-deep-relaxation-affects-brain-chemistry) [[../../../knowledge/human/строение/Симпатическая нервная система|симпатическую нервную систему]]. Как результат - снижается уровень [кортизола](Кортизол.md).
-
-После сессии медитации меняется даже активность мозга во время сна - это видно в исследованиях, проведенных с использованием ЭЭГ. Также эффективный и [доказанный](https://www.researchgate.net/publication/227735096_Practitioners_of_vipassana_meditation_exhibit_enhanced_slow_wave_sleep_and_REM_sleep_states_across_different_age_groups) способ увеличить долю ценного [глубокого сна](Фазы%20сна.md).
-
-Помимо влияния на сон, медитация имеет много других подтвержденных эффектов, влияющих на продуктивность и не только. В англоязычной Википедии есть [большая статья,](https://en.wikipedia.org/wiki/Research_on_meditation) посвященная не в целом медитации, а именно ее научно доказанным свойствам. В частности, она очень эффективна против [стресса](Стресс.md). А в [[2019]] году в течение 3-недельного эксперимента благодаря медитации испытуемые [стали удерживать внимание на 24% эффективнее.](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6329416/)
-
-Многие ошибочно полагают, что медитировать можно только сидя в позе лотоса, с закрытыми глазами и обязательно под музыку или речь диктора. Но это совсем не так. Медитировать и тренировать внимание можно во время любых действий, которые обычно делаешь на [[Режим автопилота мозга|автоматизме]].
-
-Медитация помогает расслабиться и эмоционально, за счет [удаления](https://academic.oup.com/scan/article/2/4/259/1676806/Mindfulness-training-and-neural-integration) ранее сформированных нервных связей.
-
-***
-## Мета информация
-**Область**:: [[../meta/zero/00 Осознанность|00 Осознанность]]
-**Родитель**:: 
-**Источник**:: 
-**Автор**:: 
-**Создана**:: [[2023-09-20]]
-### Дополнительные материалы
- [Effects of meditation - Wikipedia](https://en.wikipedia.org/wiki/Effects_of_meditation#Changes_in_the_brain)
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
--- a/осознанности.md
+++ b/осознанности.md
@ -1,21 +0,0 @@
---
-aliases: 
-tags:
-  - maturity/🌱
-date: 2025-01-11
---
-Практики осознанности имеют отличную доказанную эффективность в этом деле, что было показано во [многих исследованиях.](https://en.wikipedia.org/wiki/Effects_of_meditation#cite_note-Walsh_e10844-18) К примеру, в [[2019]] году в течение 3-недельного эксперимента благодаря [[Медитация|медитации]] испытуемые [стали удерживать внимание на 24% эффективнее.](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6329416/)
-
-***
-## Мета информация
-**Область**:: [[../meta/zero/00 Осознанность|00 Осознанность]]
-**Родитель**:: [[../Практики|Практики]]
-**Источник**:: 
-**Создана**:: [[2025-01-11]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/awareness/Режим
+++ b/awareness/Режим
@ -1,24 +0,0 @@
---
-aliases:
-  - автопилот
-  - автопилоте
-  - автопилота
-  - автоматизме
-tags:
-  - maturity/🌱
-date: "[[2023-10-18]]"
---
-Существенная часть жизни людей проходит в «режиме автопилота». Человеческий мозг стремится к оптимизации и экономии [[../../../knowledge/human/ресурсы/Энергия организма|энергии]]. Чтобы делать твое существование более эффективным, часть действий [не осознается](https://www.researchgate.net/publication/227344004_Mindless_Eating_The_200_Daily_Food_Decisions_We_Overlook) и предпринимается на автомате.
-
-В общем и целом, такой режим весьма полезен — он позволяет не тратить [мыслетопливо](Мыслетопливо.md) на повторяющуюся [рутину](Рутина.md). Но некоторые так сильно привыкают к автопилоту, что ручное управление уже просто не включается. Практики [осознанности](../../../garden/ru/meta/zero/00%20Осознанность.md) как раз помогают сосредоточить свое внимание на текущем моменте и прожить его полноценно.
-***
-## Мета информация
-**Область**:: [[../meta/zero/00 Осознанность|00 Осознанность]]
-**Родитель**:: 
-**Источник**:: 
-**Автор**:: 
-**Создана**:: [[2023-10-18]]
-### Дополнительные материалы
- 
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
--- a/IDentifier.md
+++ b/IDentifier.md
@ -41,7 +41,7 @@ UUID версии 1 использует текущее время по григ

 UUID версии 3 (V3) — это идентификатор, основанный на алгоритме хеширования [[cryptography/MD5|MD5]]. В отличие от UUID версии 1, который использует текущее время, UUID V3 генерируется на основе имени (строки) и пространства имен (namespace). Основная идея заключается в том, что при использовании одинаковых имени и пространства имен результатом всегда будет один и тот же UUID.

-**Пример использования:** Когда нужно сгенерировать уникальный идентификатор для имени домена в сети, применяется UUID V3 с пространством имен [[network/Domain Name System|DNS]] и строкой, содержащей доменное имя. Например:
+**Пример использования:** Когда нужно сгенерировать уникальный идентификатор для имени домена в сети, применяется UUID V3 с пространством имен **DNS** и строкой, содержащей доменное имя. Например:

 ```
 UUID(DNS, "example.com") → 5df41881-3aed-3515-88a7-2f4a814cf09e
--- a/dev/architecture/Architecture
+++ b/dev/architecture/Architecture
@ -1,40 +0,0 @@
---
-aliases:
-  - ASR
-tags:
-  - maturity/🌱
-date: 2024-09-17
---
-Architecture Significant Requirement (ASR), или архитектурно значимое требование, — это требование, которое существенно влияет на архитектурные решения системы. ASR определяет, какие аспекты архитектуры должны быть приоритетными для обеспечения нужных характеристик системы:
- Производительность
- Доступность
- Поддерживаемость
- Масштабируемость
- Удобство использования
- Совместимость
- Тестируемость
- Модифицируемость
- Переносимость
- Функциональность
- Переиспользуемость
- Диагностируемость
- Надежность
-
-**Основные характеристики ASR:**
- **Влияние на архитектуру:** Эти требования требуют определённых архитектурных решений или ограничений, чтобы обеспечить нужное поведение системы. Например, требование к высокой доступности системы может повлиять на выбор распределённой архитектуры.
- **Непосредственное влияние на атрибуты качества:** ASR нацелены на достижение или улучшение одного или нескольких атрибутов качества системы. Например, требования к времени отклика будут влиять на решения, касающиеся оптимизации производительности.
- **Долгосрочный эффект:** ASR обычно имеют долговременные последствия, так как изменение архитектурных решений позднее в процессе разработки может быть сложным и дорогостоящим.
-
-
-***
-## Мета информация
-**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: 
-**Источник**:: 
-**Создана**:: [[2024-09-17]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
--- a/dev/architecture/CAP
+++ b/dev/architecture/CAP
@ -1,6 +1,5 @@
 ---
-aliases:
-  - CAP-теорема
+aliases: 
 tags:
  - maturity/🌱
 date:
@ -9,11 +8,11 @@ date:
 ![[../../meta/files/images/Pasted image 20241103022605.png]]

 CAP теорема — это принцип, описывающий фундаментальные ограничения, с которыми сталкиваются распределённые вычислительные системы в контексте обеспечения следующих трёх свойств:
- **Согласованность** ([[Согласованность данных|Consistency]]): Каждый раз, когда данные читаются, возвращается самое последнее записанное значение или ошибка. С другими словами, операции с данными выглядят так, будто выполняются в некоторой строгой последовательности, одна за другой
- **Доступность** ([[../../../../_inbox/Availability|Availability]]): Каждый запрос на получение или запись данных получает ответ, независимо от состояния системы, даже если некоторые части системы вышли из строя.
+- **Согласованность (Consistency)**: Каждый раз, когда данные читаются, возвращается самое последнее записанное значение или ошибка. С другими словами, операции с данными выглядят так, будто выполняются в некоторой строгой последовательности, одна за другой
+- Доступность ([[../../../../_inbox/Availability|Availability]]): Каждый запрос на получение или запись данных получает ответ, независимо от состояния системы, даже если некоторые части системы вышли из строя.
 - **Устойчивость к разделению (Partition Tolerance)**: Система продолжает функционировать, даже если произошло "разделение" — потеря связи между узлами в распределённой сети. То есть система способна переносить произвольное число сообщений, которые задерживаются или теряются в сети.

-==Согласно теореме CAP, в любой момент времени система может обеспечивать только два из этих трёх свойств.== Это означает, что при разработке системы приходится принимать компромисс между этими свойствами в зависимости от требований приложения и условий эксплуатации. Например, если для системы критически важна [[согласованность данных]] и её устойчивость к разделению, возможно придётся пожертвовать её доступностью в некоторых сценариях.
+==Согласно теореме CAP, в любой момент времени система может обеспечивать только два из этих трёх свойств.== Это означает, что при разработке системы приходится принимать компромисс между этими свойствами в зависимости от требований приложения и условий эксплуатации. Например, если для системы критически важна согласованность данных и её устойчивость к разделению, возможно придётся пожертвовать её доступностью в некоторых сценариях.
 ## Свободные заметки
 - Google заявляет, что их продукт Google Spanner якобы нарушает CAP теорему.
 ***
--- a/dev/architecture/Change
+++ b/dev/architecture/Change
@ -1,56 +0,0 @@
---
-aliases:
-  - CDC
-tags:
-  - maturity/🌱
-date: 2025-01-13
---
-**Change Data Capture (CDC)** — это технология для отслеживания изменений в данных [[../../meta/zero/00 Реляционная база данных|базы данных]] (вставка, обновление, удаление) и публикации этих изменений в виде событий для других систем. CDC играет ключевую роль в построении [[Событийно-ориентированная архитектура|событийных архитектур]] и интеграции данных между системами.
-
-**Применение CDC**
- **Миграция данных**. Перенос данных между системами с минимальными простоями.
- **Событийные системы**. Построение архитектур, где изменения в данных становятся триггерами для выполнения действий.
- **Аналитика в реальном времени**. Передача данных в системы аналитики (например, ClickHouse, Elasticsearch).
- **Интеграция приложений**. Связывание разнородных систем через обмен данными.
-
-**Преимущества CDC**
- **Синхронизация данных в реальном времени**. Автоматическое обновление данных между системами.
- **Снижение нагрузки на базу данных**. Обрабатываются только изменения, а не полные данные.
- **Поддержка событийной архитектуры**. Преобразует изменения в события, которые могут обрабатываться асинхронно.
- **Простота интеграции**. Позволяет связывать разные приложения и системы через единый механизм передачи данных.
-
-**Основные подходы к реализации CDC**
- **Журнал транзакций (Transaction Logs)**. Изменения отслеживаются с помощью анализа журнала транзакций базы данных (логов WAL, redo, binlog).
-	- **Плюсы**: Высокая производительность, минимальная нагрузка на базу данных.
-	- **Минусы**: Требует доступа к журналу транзакций, ограниченная поддержка некоторых баз.
- **Триггеры в базе данных**. Изменения фиксируются с помощью триггеров, которые вызываются при выполнении операций (вставка, обновление, удаление).
-	- **Плюсы**: Простота настройки.
-	- **Минусы**: Снижение производительности базы данных, сложность поддержки.
- **Опрос данных (Polling)**. Система периодически проверяет таблицы базы данных на наличие изменений.
-	- **Плюсы**: Простая реализация.
-	- **Минусы**: Высокая нагрузка на базу данных, задержки между изменениями и их обработкой.
-
-**Инструменты для CDC**
- **Debezium**
-	- Open-source решение для CDC.
-	- Поддерживает PostgreSQL, MySQL, MongoDB, Oracle и другие.
-	- Интегрируется с Kafka для публикации событий.
- **Oracle GoldenGate**
-	- Коммерческий продукт для CDC.
-	- Высокая производительность, поддержка множества СУБД.
- **Striim**
-	- Платформа для потоковой обработки данных с поддержкой CDC.
-	- Включает инструменты визуализации и настройки ETL.
-***
-## Мета информация
-**Область**:: [[Архитектурный паттерн]]
-**Родитель**:: [[Интеграция информационных систем|Интеграция информационных систем]]
-**Источник**:: 
-**Создана**:: [[2025-01-13]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/dev/architecture/Database
+++ b/dev/architecture/Database
@ -24,7 +24,7 @@ date: 2024-11-24
 Лучшие практики
 - **Чёткие границы владения данными**. Определите чёткие границы владения данными для каждого сервиса, - [[Bounded Context|Ограниченный контекст]]. Это помогает избежать пересечений и зависимостей между сервисами, а также упрощает управление данными.
 - [[Событийно-ориентированная архитектура|Событийно-ориентированная архитектура]]. Для обеспечения согласованности данных между микросервисами можно использовать события. Например, при изменении данных в одном сервисе он отправляет событие, на которое подписаны другие сервисы, которым эти данные могут быть нужны.
- **Реализация паттернов для согласованности**. Используйте паттерны, такие как [Saga](Реализация%20повествования%20(Saga).md), чтобы координировать действия между несколькими микросервисами и гарантировать [[согласованность данных]] без использования глобальных транзакций.
+- **Реализация паттернов для согласованности**. Используйте паттерны, такие как [Saga](Реализация%20повествования%20(Saga).md), чтобы координировать действия между несколькими микросервисами и гарантировать согласованность данных без использования глобальных транзакций.
 - **API вместо прямого доступа к данным**. Доступ к данным одного микросервиса другими должен осуществляться только через публичные API. Это помогает соблюдать [[Инкапсуляция|инкапсуляцию]] и обеспечивает безопасное взаимодействие между сервисами.
 ***
 ## Мета информация
--- a/dev/architecture/Event
+++ b/dev/architecture/Event
@ -27,7 +27,7 @@ Event Sourcing — это [[архитектурный паттерн]], при
 1. **Финансовые системы**. Для учета транзакций и обеспечения полного логирования операций.
 2. **E-commerce**. Хранение всех изменений корзины пользователя или заказов.
 3. **IoT**. Сохранение событий от датчиков для анализа в реальном времени или ретроспективы.
-4. Паттерн [[../../../../knowledge/dev/архитектура/паттерн/Command Query Responsibility Segregation|Command Query Responsibility Segregation]]. Часто используется совместно с Event Sourcing для разделения операций чтения и записи.
+4. Паттерн [[../../../../knowledge/dev/архитектура/паттерн/CQRS|CQRS]]. Часто используется совместно с Event Sourcing для разделения операций чтения и записи.
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
--- a/dev/architecture/Infrastructure
+++ b/dev/architecture/Infrastructure
@ -1,39 +0,0 @@
---
-aliases:
-  - IaC
-tags:
-  - maturity/🌱
-date: 2024-12-21
---
-Infrastructure as Code (IaC) — это практика управления, конфигурирования и автоматизации вычислительных ресурсов (серверов, сетей, баз данных и т.д.) с использованием программного кода. Она позволяет инфраструктуре быть определённой в виде описания, которое можно сохранить в системе контроля версий, автоматически применять и изменять.
-
-Пример: создание сервера не вручную через облачный интерфейс, а с использованием скрипта, который можно запустить и повторить в любой момент.
-
-**Принципы**
- **Декларативность или императивность.** Инфраструктура описывается либо в виде желаемого состояния (декларативный подход), либо через последовательность команд (императивный подход).
- **Контроль версий.** Код инфраструктуры хранится в системах контроля версий (например, Git), что позволяет отслеживать изменения и возвращаться к предыдущим состояниям.
- [[Идемпотентность]]. Повторное выполнение кода приводит к одному и тому же результату, что важно для стабильности.
-
-**Преимущества**
- **Стандартизация.** Все ресурсы управляются одинаково, снижается риск ошибок.
- **Ускорение разработки.** Быстрое развёртывание и настройка инфраструктуры.
- [[Масштабирование информационной системы|Масштабируемость]]. Удобное управление инфраструктурой даже в крупных системах.
- Упрощение [[highload/Disaster recovery|восстановления]]. Код инфраструктуры позволяет восстановить её после сбоев.
-
-**Недостатки**
- **Кривая обучения.** Требуется время на изучение инструментов и практик IaC.
- **Сложность внедрения.** Для небольших команд или простых систем реализация IaC может быть излишней.
- **Необходимость дисциплины.** Некорректное управление кодом может привести к нестабильности.
-***
-## Мета информация
-**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: [[Архитектурная концепция]]
-**Источник**:: 
-**Создана**:: [[2024-12-21]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/dev/architecture/Session
+++ b/dev/architecture/Session
@ -1,44 +0,0 @@
---
-aliases:
-  - Sticky Sessions
-tags:
-  - maturity/🌱
-date: 2025-01-17
---
-**Session Affinity** (или **Sticky Sessions**) — это подход в [[highload/Балансировка нагрузки|балансировке нагрузки]], при котором запросы от одного клиента всегда направляются на один и тот же сервер в течение всей сессии. Это обеспечивает сохранение состояния клиента на конкретном сервере и делает взаимодействие более последовательным.
-
-**Преимущества**
- **Сохранение состояния**: Не требует сложной реализации хранения состояния между серверами.
- **Простота для разработчиков**: Упрощает работу с приложениями, которые не являются [[Stateless Service|stateless]].
-
-**Недостатки**
- **Риски перегрузки**: Сервер, привязанный к большому количеству клиентов, может стать перегруженным.
- **Уязвимость к сбоям**: Если сервер выходит из строя, сессии клиентов теряются.
- Меньшая гибкость [[Масштабирование информационной системы|масштабирования]]: Динамическое добавление или удаление серверов затруднено.
-
-**Методы реализации**
- **По IP-адресу клиента**:
-    - Сервер выбирается на основе IP-адреса клиента.
-    - Простая реализация, но уязвима к использованию прокси-серверов и NAT.
- **По cookie**:
-    - Балансировщик устанавливает [[../network/Cookie|cookie]] на клиенте, где хранится информация о назначенном сервере.
-    - Наиболее популярный метод благодаря своей гибкости.
- **На основе токена**:
-	- Клиент предоставляет токен (например, JWT), который указывает на сервер, обрабатывающий сессию.
-	- Токен может быть частью механизма аутентификации.
- **Hash-Based (Хеширование)**:
-	- Сервер определяется через хеширование идентификатора клиента (например, IP, ID пользователя или URL).
-	- Эффективен для систем с большим количеством пользователей.
-***
-## Мета информация
-**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: [[highload/Балансировка нагрузки|Балансировка нагрузки]]
-**Источник**:: 
-**Создана**:: [[2025-01-17]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/dev/architecture/Stateless
+++ b/dev/architecture/Stateless
@ -1,32 +0,0 @@
---
-aliases:
-  - Stateless
-  - Stateless-сервисы
-tags:
-  - maturity/🌱
-date: 2025-01-17
---
-**Stateless-приложения** — это приложения или сервисы, которые обрабатывают каждый запрос как независимое событие, не полагаясь на сохранение данных между запросами. Вся необходимая информация для выполнения запроса должна передаваться в рамках самого запроса.
-
-**Преимущества:**
- [[Масштабирование информационной системы|Масштабируемость]]: Простота [[highload/Горизонтальное масштабирование|горизонтального масштабирования]] за счет отсутствия необходимости синхронизации состояния между серверами.
- **Отказоустойчивость**: Выход из строя одного сервера не влияет на другие. Пользователь может обратиться к любому серверу в кластере, и запрос будет обработан корректно.
- **Упрощенное управление**: Легче деплоить и управлять, так как не требуется репликация состояния.
- Совместимость с [[highload/Балансировка нагрузки|балансировкой нагрузки]]: Подход хорошо интегрируется с алгоритмами балансировки, такими как Round Robin или Least Connections.
-
-**Недостатки**
- **Необходимость внешнего хранилища**: Для хранения состояния используются базы данных, кэши (Redis, Memcached) или другие системы. Это может увеличить задержки при доступе к данным.
- **Более сложные запросы**: Поскольку сервер не помнит пользователя, клиент должен передавать всю необходимую информацию в каждом запросе (например, токены аутентификации, данные контекста).
-***
-## Мета информация
-**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: 
-**Источник**:: 
-**Создана**:: [[2025-01-17]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/dev/architecture/Transactional
+++ b/dev/architecture/Transactional
@ -2,8 +2,6 @@
 aliases:
  - transactional outbox
  - транзакционный аутбокс
-  - Outbox-паттерн
-  - Outbox Pattern
 tags:
  - maturity/🌱
 date: 2024-11-15
@ -18,7 +16,7 @@ Transactional Outbox — это [[Паттерн проектирования|ш

 **Преимущества:**
 - **Гарантированная доставка сообщений**: сообщения фиксируются вместе с бизнес-операциями, что предотвращает ситуацию, когда данные в базе данных обновлены, а сообщение не отправлено.
- **Упрощение архитектуры**: использование таблицы `outbox` вместо распределённых транзакций ([[../fundamental/Two-Phase Commit|2PC]]) значительно упрощает архитектуру и позволяет избежать сложных механизмов блокировки.
+- **Упрощение архитектуры**: использование таблицы `outbox` вместо распределённых транзакций (2PC) значительно упрощает архитектуру и позволяет избежать сложных механизмов блокировки.

 **Недостатки:**
 - **Дополнительная задержка**: отправка сообщений через фоновый процесс может вызвать небольшую задержку в доставке сообщений, по сравнению с немедленной отправкой.
--- a/dev/architecture/highload/Disaster
+++ b/dev/architecture/highload/Disaster
@ -1,40 +0,0 @@
---
-aliases:
-  - DR
-  - восстановления
-  - восстановление
-tags:
-  - maturity/🌱
-date:
-  - - 2024-03-05
---
-Disaster Recovery (восстановление после сбоев) — это совокупность мер, направленных на восстановление [[Информационная система|ИТ-систем]] и операций после серьёзных сбоев, включая аппаратные отказы, кибератаки, природные катастрофы и ошибки пользователей. DR-планы разрабатываются для снижения времени простоя, минимизации потерь данных и обеспечения непрерывности бизнеса.
-
-Одна из ключевых проблем в DR — это потеря данных. В большинстве сценариев невозможно полностью избежать этой потери, особенно если системы не были спроектированы с высокой степенью [[Reliability|отказоустойчивости]]. Тем не менее, применение современных технологий может значительно сократить объём утраченных данных.
-
-Для оценки эффективности DR используются следующие метрики:
- **RTO (Recovery Time Objective).** Максимально допустимое время восстановления системы.
- **RPO (Recovery Point Objective).** Максимально допустимый объём данных, который можно потерять без критического ущерба.
-
-Разработка эффективного DR-плана включает:
-1. **Анализ рисков.** Выявление возможных угроз и их последствий.
-2. **Выбор стратегии.** Определение метрик RTO и RPO, а также подходящих технологий восстановления.
-3. **Создание документации.** Подробный план действий в случае сбоя.
-4. **Тестирование.** Регулярное проведение тестов на соответствие плана реальным угрозам.
-5. **Обновление.** Корректировка плана в зависимости от изменений в инфраструктуре или бизнес-процессах.
-
-**Методы и инструменты DR**
- Резервное копирование
-	- [[Резервное копирование БД]]
- [[Репликация|Репликация]]
-***
-## Мета информация
-**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
-**Родитель**:: 
-**Источник**:: 
-**Автор**:: 
-**Создана**:: [[2024-04-05]]
-### Дополнительные материалы
- 
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
--- a/dev/architecture/highload/Балансировка
+++ b/dev/architecture/highload/Балансировка
@ -5,9 +5,6 @@ aliases:
  - балансировщики нагрузки
  - балансировщиком нагрузки
  - балансировщиком
-  - балансировке нагрузки
-  - алгоритмами балансировки
-  - балансировкой нагрузки
 tags:
  - maturity/🌱
 date: 2024-06-13
@ -15,16 +12,14 @@ date: 2024-06-13
 ![[../../../meta/files/images/Pasted image 20241103021050.png]]

 **Статические алгоритмы**
- **Round robin**. Запросы от клиентов отправляются поочередно разным экземплярам сервиса. Как правило, сервисы должны быть [[../Stateless Service|stateless]] (не сохранять состояние между запросами).
+- **Round robin**. Запросы от клиентов отправляются поочередно разным экземплярам сервиса. Как правило, сервисы должны быть stateless (не сохранять состояние между запросами).
 - **Sticky round-robin** Улучшенная версия алгоритма round robin. Если первый запрос от Алисы попал на сервис A, то и все последующие её запросы будут отправляться на этот же сервис A.
 - **Weighted round-robin** Администратор может задать вес для каждого сервиса. Сервисы с большим весом будут обрабатывать больше запросов, чем другие.
 - **Hash (Хеширование)** Этот алгоритм применяет хеш-функцию к IP-адресу или URL запроса. Запросы направляются на соответствующие экземпляры сервиса в зависимости от результата [[../../cryptography/Хеш-функция|хеш-функции]].
- [[../Session Affinity|Session Affinity]]
  
 **Динамические алгоритмы**
 - **Least connections**. Новый запрос отправляется экземпляру сервиса с наименьшим числом текущих соединений.
 - **Least response time.** Новый запрос отправляется на экземпляр сервиса с самым быстрым временем отклика.
- **Adaptive Load Balancing**. Использует мониторинг серверов и их текущей нагрузки (CPU, RAM, сетевые ресурсы). Запрос направляется на наиболее “свободный” сервер.

 ***
 ## Мета информация
@ -37,6 +32,3 @@ date: 2024-06-13
 - 
 ### Дочерние заметки
 <!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
- [[Session Affinity]]
-<!-- SerializedQuery END -->
--- a/dev/architecture/highload/Горизонтальное
+++ b/dev/architecture/highload/Горизонтальное
@ -17,7 +17,7 @@ date:
 **Проблемы:**
 1. **Сложность управления**: Управление множеством узлов и их координация может быть значительно сложнее, чем управление одним мощным сервером. Нужно делать балансировку вызовов.
 2. **Сложность разработки**: Разработка приложений, способных эффективно использовать ресурсы в распределенной среде, может быть более сложной, а значит программисты обходятся дороже.
-3. [[../Согласованность данных|Согласованность данных]]: Обеспечение согласованности данных между множеством узлов может представлять собой вызов, особенно в системах, где требуется высокий уровень согласованности.
+3. **Согласованность данных**: Обеспечение согласованности данных между множеством узлов может представлять собой вызов, особенно в системах, где требуется высокий уровень согласованности.
 4. **Затраты на сеть**: Горизонтальное масштабирование может повлечь за собой увеличенные затраты на сетевое оборудование и управление сетью, особенно если узлы географически распределены.

 Частные проблемы:
--- a/dev/architecture/highload/Групповая
+++ b/dev/architecture/highload/Групповая
@ -14,7 +14,7 @@ linked:

 - Все транзакции чтения и записи фиксируются только после того, как они были одобрены группой.
 - Read-only транзакции не требуют координации внутри группы и фиксируются немедленно
- Групповая репликация - [[../Еventual consistency|Еventual consistency]] система
+- Групповая репликация - eventual consistency система

 ![](../../../meta/files/images/Pasted%20image%2020240605091036.png)

--- a/dev/architecture/highload/Монотонное
+++ b/dev/architecture/highload/Монотонное
@ -1,7 +1,5 @@
 ---
-aliases:
-  - Monotonic Read Consistency
-  - Monotonic Read
+aliases: 
 tags:
  - maturity/🌱
 date:
--- a/dev/architecture/highload/Репликация
+++ b/dev/architecture/highload/Репликация
@ -17,7 +17,7 @@ linked:
 ## Тезисы
 - Репликация это копирование измененных данных с одного сервера БД на другой.
 - Не отменяет первоначального копирования БД. Сначала нужно первый раз скопировать данные, а потом уже запустить репликацию.
- Репликация не является [резервной копией БД](../../../../../_inbox/Резервное%20копирование%20БД.md).
+- Репликация не является [резервной копией БД](Резервные%20копии%20БД.md).
 - Обычно реализуются на базе [[../../database/Журнал БД|журнала БД]].
 - Плюсы:
 	- Помогает улучшить [Availability](../../../../../_inbox/Availability.md). Помогает при падении.
@ -38,7 +38,7 @@ linked:
 **Для чего делают репликацию?**
 - [[../../../../../_inbox/Availability|Availability]]. Если один сервер выходит из строя, другие реплики продолжают обслуживать запросы, обеспечивая непрерывный доступ к данным.
 - **Масштабирование чтения**. Нагрузка на чтение может быть распределена между несколькими репликами, что улучшает производительность системы.
- **Распределение нагрузки**. Сложные аналитические запросы для построения отчетов и асинхронное [резервное копирование БД](../../../../../_inbox/Резервное%20копирование%20БД.md) могут выполняться на отдельных репликах, не нагружая основной сервер.
+- **Распределение нагрузки**. Сложные аналитические запросы для построения отчетов и асинхронное [резервное копирование БД](Резервные%20копии%20БД.md) могут выполняться на отдельных репликах, не нагружая основной сервер.
 - **Географическое распределение**. Реплики могут быть размещены ближе к пользователям в разных регионах, уменьшая задержки доступа к данным.

 **Недостатки репликации:**
--- a/dev/architecture/Архитектура
+++ b/dev/architecture/Архитектура
@ -1,40 +0,0 @@
---
-aliases:
-  - AaC
-tags:
-  - maturity/🌱
-date: 2024-12-21
---
-Архитектура as Code (AaC) — это методология, при которой архитектурные решения и схемы описываются с использованием программного кода. Подход вдохновлен концепцией [[Infrastructure as Code]] (IaC), но применяется к более высокоуровневым аспектам системы, таким как взаимодействие сервисов, модули, [[Контракт взаимодействия|контракты]] и зависимости.
-
-Пример: вместо создания диаграммы вручную, архитектура описывается в YAML или JSON-файле, который затем может быть интерпретирован для создания визуализации или проверки соответствия системе.
-
-**Основные принципы**
- **Декларативность.** Архитектура описывается в виде декларативного файла, который служит источником правды для всей команды.
- **Автоматизация.** Использование кода для автоматической проверки архитектурных решений и их применения.
- **Интеграция.** Возможность связки с CI/CD пайплайнами для проверки соответствия архитектурным стандартам.
- **Версионность.** Все изменения архитектуры фиксируются в системе контроля версий, что позволяет отслеживать её эволюцию.
-
-**Ограничения**
- **Сложность внедрения.** Требуются опыт и компетенции команды для реализации подхода.
- **Обучение.** Необходимо обучать специалистов работать с инструментами AaC.
- **Необходимость дисциплины.** Без четкого подхода может возникнуть хаос в коде архитектуры.
-
-**Инструменты**
- [Structurizr](https://structurizr.com) — для описания архитектуры на основе C4-модели.
- OpenAPI/AsyncAPI — для описания API.
- Terraform, Pulumi — для связи архитектурного описания с инфраструктурой.
- DSL (Domain-Specific Languages) — собственные языки для описания архитектуры.
-***
-## Мета информация
-**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: 
-**Источник**:: 
-**Создана**:: [[2024-12-21]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/dev/architecture/Архитектурная
+++ b/dev/architecture/Архитектурная
@ -4,7 +4,7 @@ tags:
  - maturity/🌱
 date: 2024-11-26
 ---
-Архитектурные карты — это **визуальное представление** системы, ее структуры, связей и компонентов. Они служат инструментом для анализа, проектирования и коммуникации, упрощая понимание системы всеми заинтересованными сторонами: разработчиками, аналитиками, архитекторами и бизнес-заказчиками.
+Архитектурные карты — это визуальное представление системы, ее структуры, связей и компонентов. Они служат инструментом для анализа, проектирования и коммуникации, упрощая понимание системы всеми заинтересованными сторонами: разработчиками, аналитиками, архитекторами и бизнес-заказчиками.

 Архитектурная карта может включать в себя несколько [[Архитектурная схема|архитектурных схем]].

@ -14,6 +14,8 @@ date: 2024-11-26
 - **Выявление “слепых зон”**. Визуализация выявляет незадокументированные связи, зависимости и потенциальные уязвимости.
 - **Анализ и планирование изменений**. Карты позволяют моделировать изменения, предсказывать их влияние и оценивать риски.

+  
+
 **Виды архитектурных карт**
 - **Концептуальные карты**. Они описывают общую идею системы и ее назначение.
 	- Упор на крупные блоки системы (например, модули или бизнес-процессы).
@ -42,7 +44,4 @@ date: 2024-11-26

 ### Дочерние заметки
 <!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
- [[Архитектурная схема]]
-<!-- SerializedQuery END -->

--- a/dev/architecture/Архитектурная
+++ b/dev/architecture/Архитектурная
@ -1,7 +1,5 @@
 ---
-aliases:
-  - архитектурных принципов
-  - архитектурный принцип
+aliases: 
 tags:
  - maturity/🌱
 date: 2024-10-01
@ -17,7 +15,6 @@ date: 2024-10-01

 Прочие концепции:
 - [[Inversion of Control]]
- [[Infrastructure as Code]]
 - [[Один клиент — один поток]]
 - [[Много клиентов — один поток]]
 ***
@ -39,5 +36,5 @@ date: 2024-10-01
 - [[Много клиентов — один поток]]
 - [[Один клиент — один поток]]
 - [[Паттерн проектирования]]
- [[Infrastructure as Code]]
+- [[Событийно-ориентированная архитектура]]
 <!-- SerializedQuery END -->
--- a/dev/architecture/Архитектурная
+++ b/dev/architecture/Архитектурная
@ -8,8 +8,6 @@ date: 2024-11-26
 ---
 Архитектурная схема — это детализированное визуальное представление структуры и функционирования системы. Она помогает понять, как устроена система, какие компоненты входят в её состав и как они взаимодействуют друг с другом.

-Архитектурная схема позволяет уменьшить [[../../psychology/Семантический разрыв|семантический разрыв]] при технических обсуждениях.
-
 **Основная цель архитектурной схемы**
 - **Технической документации** — фиксации текущего состояния системы.
 - **Разработки и тестирования** — схемы позволяют командам лучше понимать структуру системы и её компоненты.
@ -38,11 +36,16 @@ date: 2024-11-26
 - **Обеспечьте ясность**. Убедитесь, что схема легко читается, избегайте избыточной детализации. Используйте условные обозначения и комментарии.
 - **Актуализируйте схему**. При изменении системы своевременно вносите изменения в схему, чтобы она оставалась полезной.

-Лучше всего использовать подход [[Архитектура as Code]], чтобы иметь возможность видеть эволюцию схемы.
+**Пример архитектурной схемы**
+Представьте распределённую систему с микросервисной архитектурой. Архитектурная схема может включать:
+- Микросервисы (компоненты) и их функции.
+- API и форматы данных для взаимодействия между сервисами.
+- Потоки данных между сервисами и базами данных.
+- Инфраструктуру развёртывания (например, кластер Kubernetes, базы данных, брокеры сообщений).
 ***
 ## Мета информация
-**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: [[Архитектурная карта]]
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]]]
+**Родитель**:: 
 **Источник**:: 
 **Создана**:: [[2024-11-26]]
 **Автор**:: 
--- a/dev/architecture/Архитектурный
+++ b/dev/architecture/Архитектурный
@ -14,10 +14,6 @@ date: 2024-12-02
 - [[Событийно-ориентированная архитектура]]

 - [[Event Sourcing]]
- [[../../../../knowledge/dev/архитектура/паттерн/Command Query Responsibility Segregation|CQRS]]
-
-Миграция/синхронизация данных:
- [[Change Data Capture|Change Data Capture]]
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
@ -34,8 +30,6 @@ date: 2024-12-02
 - [[Event Sourcing]]
 - [[Serverless]]
 - [[Монолитная архитектура]]
- [[Событийно-ориентированная архитектура]]
 - [[00 Микросервисная архитектура]]
- [[Command Query Responsibility Segregation]]
 <!-- SerializedQuery END -->

--- a/dev/architecture/Еventual
+++ b/dev/architecture/Еventual
@ -1,22 +0,0 @@
---
-aliases:
-  - Конечная согласованность
-  - eventual consistency
-tags:
-  - maturity/🌱
-date: 2025-01-15
---
-
-***
-## Мета информация
-**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: [[Согласованность данных|Согласованность данных]]
-**Источник**:: 
-**Создана**:: [[2025-01-15]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/dev/architecture/Идемпотентность.md
+++ b/dev/architecture/Идемпотентность.md
@ -5,8 +5,6 @@ aliases:
  - идемпотентности
  - идемпотентную
  - идемпотентные
-  - Идемпотентные операции
-  - Idempotence
 tags:
  - maturity/🌱
 date: 2024-09-11
--- a/dev/architecture/Избыточность
+++ b/dev/architecture/Избыточность
@ -26,7 +26,7 @@ date: 2024-11-24
 2. **Увеличение объёма хранилища**. Хранение данных в нескольких формах требует больше места в хранилище. Для высоконагруженных систем с большими объёмами данных это может стать значительным фактором.

 Лучшие практики для работы с избыточностью данных
-1. **Продуманная архитектура синхронизации**. Используйте [[Событийно-ориентированная архитектура|событийную архитектуру]], чтобы поддерживать [[согласованность данных]]. Например, при добавлении нового сообщения можно отправить событие, которое обновит индекс последних сообщений.
+1. **Продуманная архитектура синхронизации**. Используйте [[Событийно-ориентированная архитектура|событийную архитектуру]], чтобы поддерживать согласованность данных. Например, при добавлении нового сообщения можно отправить событие, которое обновит индекс последних сообщений.
 2. **Оценка необходимости избыточности**. Вводите избыточность только там, где это действительно необходимо для повышения производительности или удобства работы. Не стоит избыточно усложнять систему там, где этого можно избежать.
 3. **Мониторинг консистентности**. Внедряйте механизмы проверки и восстановления консистентности данных между копиями. Это поможет вовремя обнаружить и устранить расхождения.

--- a/dev/architecture/Интеграция
+++ b/dev/architecture/Интеграция
@ -1,24 +0,0 @@
---
-aliases: 
-tags:
-  - maturity/🌱
-date: 2025-01-13
---
-Подходы:
- [[Change Data Capture]]
-***
-## Мета информация
-**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: 
-**Источник**:: 
-**Создана**:: [[2025-01-13]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
- [[Change Data Capture]]
-<!-- SerializedQuery END -->
-
--- a/dev/architecture/Кэширование.md
+++ b/dev/architecture/Кэширование.md
@ -33,7 +33,7 @@ linked:
 - [Кэширование на стороне браузера](highload/Кэширование%20на%20стороне%20браузера.md). Ответы HTTP могут кэшироваться браузером. При первом запросе данных по HTTP они возвращаются с политикой истечения срока действия в заголовке HTTP. При повторном запросе данных клиентское приложение сначала пытается получить их из кэша браузера.
 - [Кэширование на стороне Nginx](../devops/nginx/Кэширование%20на%20стороне%20Nginx.md)
 - [Content Delivery Network](highload/Content%20Delivery%20Network.md). CDN кэширует статические веб-ресурсы. Клиенты могут получать данные с ближайшего узла CDN.
- [[highload/Балансировка нагрузки|Балансировщик нагрузки]]: Балансировщик также может кэшировать ресурсы.
+- **Балансировщик нагрузки**: Балансировщик также может кэшировать ресурсы.
 - [Кэширование в приложении](Кэширование%20в%20приложении.md). В сервисах есть несколько уровней кэша. Если данные не находятся в кэше процессора, сервис пытается получить их из памяти. Иногда в сервисе есть вторичный уровень кэша для хранения данных на диске.
 - **Распределённый кэш**: Распределённые кэши, такие как Redis, хранят пары ключ-значение в памяти для множества сервисов. Это обеспечивает значительно лучшую производительность чтения и записи по сравнению с базой данных.
 - **База данных**: Даже в базе данных есть различные уровни кэша
--- a/dev/architecture/Масштабирование
+++ b/dev/architecture/Масштабирование
@ -3,8 +3,6 @@ aliases:
  - масштабирование
  - масштабировании
  - масштабируемости
-  - масштабируемость
-  - масштабирования
 tags:
  - maturity/🌱
 date: 2024-12-03
--- a/dev/architecture/Монолитная
+++ b/dev/architecture/Монолитная
@ -15,7 +15,7 @@ date: 2024-04-04
 - **Лёгкость внесения радикальных изменений**. В монолитной архитектуре вы можете одновременно менять код и структуру базы данных. После этого достаточно пересобрать и развернуть новое приложение.
 - **Простота тестирования**. Сквозное тестирование охватывает всю систему сразу. Инструменты, такие как Selenium, позволяют тестировать пользовательский интерфейс, API и внутреннюю логику в одном процессе.
 - **Упрощённое развертывание**. Разработчику достаточно скопировать один WAR-файл (или аналог) на сервер с установленным приложением, например Tomcat.
- **Масштабирование путём клонирования**. Для увеличения производительности можно развернуть несколько экземпляров приложения за [[highload/Балансировка нагрузки|балансировщиком нагрузки]], распределяя трафик между ними.
+- **Масштабирование путём клонирования**. Для увеличения производительности можно развернуть несколько экземпляров приложения за балансировщиком нагрузки, распределяя трафик между ними.

 Несмотря на простоту, монолитный подход имеет **ряд ограничений**, которые могут стать критическими при увеличении размера приложения или масштабировании бизнеса:
 - **Трудности с масштабированием**. Программные модули конкурируют за ресурсы. Например, модуль обработки изображений, нагружающий CPU, может негативно влиять на стабильность других модулей.
--- a/dev/architecture/Отправка
+++ b/dev/architecture/Отправка
@ -2,20 +2,18 @@
 aliases: 
 tags:
  - maturity/🌱
-  - content/problem
 date: 2024-11-15
 ---
-Взаимодействие между [[../../../../_inbox/Транзакция БД|транзакциями базы данных]] и отправкой сообщений в [[../../../../_inbox/00 Kafka|Kafka]] может приводить к несогласованности данных. Пример проблемы: если сообщение отправлено в Kafka, но транзакция базы данных откатывается, сообщение останется в Kafka, тогда как база данных не зафиксирует изменений. Это вызывает рассинхронизацию между системами.
+Отправка сообщений в [[00 Kafka|Kafka]] из [[Транзакция БД|транзакций базы данных]] приводит к проблемам с согласованностью данных между системами, особенно в условиях распределённых систем. Если сначала происходит отправка сообщения в Kafka, а затем транзакция в БД откатывается, то сообщение останется в Kafka, но база данных не зафиксирует изменений, что приведёт к рассинхронизации данных.

-Для решения проблемы используются следующие подходы:
+Для обеспечения согласованности данных между базой данных и Kafka необходимо использовать следующие подходы:

- [[Transactional Outbox|Transactional Outbox]]. Изменения фиксируются в основной таблице базы данных и одновременно записываются в отдельную таблицу “Outbox”. Асинхронный процесс или сервис считывает записи из “Outbox” и отправляет их в Kafka. Это позволяет отделить транзакцию базы данных от отправки сообщений и гарантировать [[Согласованность данных|согласованность]].
- [[Change Data Capture]] (CDC). С помощью инструментов, таких как Debezium, отслеживаются изменения в базе данных. Эти изменения публикуются в Kafka в режиме реального времени. CDC подходит для автоматической синхронизации данных, но требует настройки и дополнительных ресурсов.
- Распределённые транзакции (двухфазный коммит). Этот подход координирует транзакции между базой данных и Kafka, гарантируя [[Согласованность данных|согласованность]]. Однако он считается сложным в реализации и менее масштабируемым, особенно в распределённых системах.
+- [[Transactional Outbox|Transactional Outbox]]. Этот подход позволяет отделить запись в базу данных от отправки сообщения в брокер. Изменения сначала фиксируются в основной таблице базы данных, а затем записываются в специальную таблицу "Outbox". Отдельный процесс или сервис асинхронно считывает из таблицы "Outbox" и отправляет сообщения в Kafka, что гарантирует согласованность данных.
+- Change Data Capture (CDC). Использование CDC с инструментами вроде Debezium позволяет отслеживать изменения в базе данных и публиковать их в Kafka. Это решение подходит для случаев, когда необходимо обеспечить автоматическую синхронизацию изменений, но может потребовать дополнительных настроек и ресурсов.
+- Распределённые транзакции (двухфазный коммит). Этот метод позволяет гарантировать согласованность между базой данных и Kafka за счёт координации транзакций между ними. Однако этот подход часто считается сложным и менее масштабируемым, особенно в распределённых системах.

-При сбоях системы возможна повторная обработка транзакций, что приводит к дублированию событий в Kafka. Это может вызвать повторное выполнение операций и привести к некорректному состоянию системы.
-
-Для предотвращения дублирования используется [[highload/Идемпотентность на базе уникального идентификатора|идемпотентность на базе уникального идентификатора]]. Пример: каждое сообщение или транзакция сопровождается уникальным идентификатором, который проверяется перед выполнением операции. Если идентификатор уже обработан, операция пропускается.
+Другая серьёзная проблема связана с возможностью двойной обработки. В случае сбоя приложения или инфраструктуры транзакции могут повторяться, приводя к дублированию событий в Kafka. Дублирование событий может вызвать некорректное состояние системы, повторное выполнение операций. Чтобы предотвратить дублирование, можно использовать следующие подходы: 
+- [[highload/Идемпотентность на базе уникального идентификатора|Идемпотентность на базе уникального идентификатора]]
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]]
--- a/dev/architecture/Распределенная
+++ b/dev/architecture/Распределенная
@ -1,21 +0,0 @@
---
-aliases:
-  - распределённой транзакции
-tags:
-  - maturity/🌱
-date: 2024-12-02
---
-
-***
-## Мета информация
-**Область**:: 
-**Родитель**:: 
-**Источник**:: 
-**Создана**:: [[2024-12-02]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/dev/architecture/Распределённая
+++ b/dev/architecture/Распределённая
@ -1,48 +0,0 @@
---
-aliases:
-  - распределенная система
-tags:
-  - maturity/🌱
-date: 2025-01-17
---
-Распределённая система — это группа независимых компьютеров, которые взаимодействуют через сеть для выполнения общей задачи. Для пользователя такая [[Информационная система|система]] выглядит как единое целое.
-
-Примеры: кластеры серверов, системы хранения данных (например, Hadoop, [[Cassandra]]), платформы потоковой обработки ([[00 Kafka|Kafka]], Flink) и блокчейн-сети.
-
-**Основные характеристики:**
- **Отсутствие общего состояния:** Каждый узел работает независимо, состояние хранится локально или реплицируется между узлами.
- **Прозрачность распределения:** Система должна скрывать сложность распределения от пользователя, обеспечивая:
-	- **Доступ**: пользователю не нужно знать, на каком узле хранятся данные.
-	- **Расположение**: данные могут быть перемещены между узлами.
-	- **Сопряжённость**: система должна справляться с частичными сбоями.
- [[Масштабирование информационной системы|Масштабируемость]]: Возможность увеличивать производительность системы за счёт добавления новых узлов.
- [[Reliability|Отказоустойчивость]]: Система продолжает работать даже при сбое отдельных компонентов.
- [[Согласованность данных|Согласованность данных]]: Обеспечение актуальности данных на всех узлах в условиях асинхронных операций.
-
-**Проблемы распределённых систем**
- Согласованность данных ([[CAP теорема|CAP-теорема]]):
-	- Система не может одновременно обеспечивать все три свойства:
-		- **Согласованность (Consistency):** Все узлы возвращают одинаковые данные.
-		- **Доступность (Availability):** Каждый запрос получает ответ, даже при сбоях.
-		- **Устойчивость к разделению (Partition Tolerance):** Система работает при разделении сети.
- **Управление отказами:** Определение, какие узлы вышли из строя, и их восстановление.
- **Сложность разработки:** Необходимость учитывать сетевые [[Latency|задержки]], частичные сбои и распределённое состояние.
- **Производительность:** Распределённые операции могут быть медленнее из-за необходимости синхронизации данных.
-
-**Модели взаимодействия**
- **Клиент-сервер:** Клиенты отправляют запросы, серверы обрабатывают их.
- **Peer-to-Peer (P2P):** Все узлы равны и взаимодействуют напрямую. Пример: BitTorrent, блокчейн.
- **Публикация-подписка (Pub/Sub):** Узлы подписываются на определённые темы и получают уведомления о новых событиях. Пример: [[../../../../_inbox/00 Kafka|Kafka]], [[../../../../_inbox/00 RabbitMQ|RabbitMQ]].
-***
-## Мета информация
-**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: [[Информационная система]]
-**Источник**:: 
-**Создана**:: [[2025-01-17]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/dev/architecture/Событийно-ориентированная
+++ b/dev/architecture/Событийно-ориентированная
@ -6,19 +6,18 @@ aliases:
  - Событийно-ориентированная архитектура
  - событийную архитектуру
  - Событийная архитектура
-  - событийных архитектур
 tags:
  - maturity/🌱
 date:
  - - 2024-03-19
 ---
-Событийно-ориентированная архитектура — это [[Архитектурный паттерн|архитектурный подход]], при котором взаимодействие между компонентами системы строится вокруг обмена и обработки событий.
+Событийно-ориентированная архитектура — это [[Архитектурный паттерн|архитектурный подход]], при котором взаимодействие между компонентами системы строится вокруг обмена и обработки событий. Вместо традиционного подхода, где компоненты напрямую вызывают методы или функции друг друга, в событийно-ориентированной архитектуре компоненты реагируют на события, которые создаются внутри системы или поступают из внешних источников.

-В этой архитектуре основной фокус направлен на поток событий и их обработку, что позволяет системам быть асинхронными и хорошо масштабируемыми. События могут представлять собой любые значимые изменения состояния или действия: от пользовательских запросов и сообщений сервисов друг другу до сигналов от внешних устройств.
+В этой архитектуре основной фокус направлен на поток событий и их обработку, что позволяет системам быть более гибкими, асинхронными и хорошо масштабируемыми. События могут представлять собой любые значимые изменения состояния или действия: от пользовательских запросов и сообщений сервисов друг другу до сигналов от внешних устройств.

 **Ключевые элементы событийно-ориентированной архитектуры:**
 1. **События (Events):** Представляют собой факты или изменения состояния, которые происходят в системе. Например, поступление сообщения в [[../../../../_inbox/00 Kafka|Kafka]], нажатие кнопки в пользовательском интерфейсе или обновление данных в хранилище.
-2. **Обработчики событий (Event Handlers):** Компоненты или сервисы, которые "подписываются" на определённые типы событий и выполняют определённые действия в ответ на их возникновение. Обработчиком может быть [[микросервис]], вызов функции или запуск определённой логики в реакцию на сигнал.
+2. **Обработчики событий (Event Handlers):** Компоненты или сервисы, которые "подписываются" на определённые типы событий и выполняют определённые действия в ответ на их возникновение. Обработчиком может быть микросервис, вызов функции или запуск определённой логики в реакцию на сигнал.
 3. **Цикл обработки событий (Event Loop) или Механизм распределения событий:** Центральный элемент, отвечающий за получение событий, их маршрутизацию и передачу нужным обработчикам. В распределённых системах его роль часто выполняет [[брокер сообщений]] или [[../../../../_inbox/Enterprise Service Bus|шина данных]].
 4. **Очередь событий (Event Queue):** Средство для буферизации и упорядочивания событий при высокой нагрузке или одновременном возникновении большого числа сигналов. Очередь обеспечивает последовательную, контролируемую обработку и повышает надёжность системы.

@ -39,16 +38,6 @@ date:
 **Недостатки:**
 - Сложность тестирования, поскольку трудно контролировать и предсказать порядок возникновения и обработки событий.
 - Повышенная сложность разработки и отладки из-за асинхронной природы взаимодействий между компонентами.
-
-**Способы отправки событий:**
- Отправлять в [[Брокер сообщений|брокеры сообщений]] события прямо из кода.
-	- [[Отправка сообщений в Kafka из транзакции БД]]
- Можно читать бинлог и отправлять в [[Брокер сообщений]]
- [[Transactional Outbox]]. Сохраняем события в БД, из которой события отправляются в [[Брокер сообщений]].
-
-**Тип отправляемых данных:**
- [[Event Sourcing]]. Отправлять только те данные, которые изменились.
- Отправлять целиком актуальные данные.
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
--- a/dev/architecture/Согласованность
+++ b/dev/architecture/Согласованность
@ -1,55 +0,0 @@
---
-aliases:
-  - Consistency
-  - согласованность
-tags:
-  - maturity/🌱
-date: 2025-01-15
---
-**Согласованность данных** — это свойство, гарантирующее, что данные в [[../../../../_inbox/Информационная система|системе]] остаются правильными и соответствуют определённым правилам после выполнения операций. Это важно как для локальных баз данных, так и для распределённых систем.
-
-**Проблемы согласованности**
- **Сетевые задержки**. [[Latency|Задержки]] или сбои в сети увеличивают сложность обеспечения согласованности.
- **Конфликты данных**. При параллельных изменениях системы должны разрешать конфликты.
- **Цена согласованности**. Чем выше уровень согласованности, тем больше задержки и ниже производительность.
-
-**Уровни согласованности**
- **Строгая согласованность (Strong Consistency)**: Все узлы системы видят одно и то же состояние данных в любой момент времени.
-	- Пример: Системы банковских счетов.
-	- Недостаток: Высокие [[Latency|задержки]], так как требуется синхронизация между всеми узлами.
- **Чтение после записи (Read-After-Write Consistency)**:
-	- После записи данных в систему любое последующее чтение возвращает обновлённое значение.
-	- Пример: Создание или обновление документа.
- [[highload/Монотонное чтение|Монотонное чтение]] (Monotonic Read Consistency):
-	- Если пользователь прочитал определённое значение данных, последующие чтения не вернут более старое состояние.
- [[Еventual consistency|Конечная согласованность]] (Eventual Consistency): Узлы системы со временем синхронизируются, но в краткосрочной перспективе данные могут быть несогласованными.
-	- Пример: Системы репликации данных, такие как [[../network/Domain Name System|Domain Name System]].
-
-**Методы обеспечения согласованности**
- **Консенсусные алгоритмы**:
-	- **Paxos, Raft**: Обеспечивают согласованность между узлами в условиях отказов.
-	- Применяются в распределённых базах данных и системах координаторов.
- **Механизмы транзакций**:
-	- [[../fundamental/Two-Phase Commit|Двухфазный коммит]] (2PC): Обеспечивает атомарность и согласованность между участниками транзакции.
-	- **Согласованное журналирование**: Используется для [[highload/Disaster recovery|восстановления]] согласованности после сбоев.
- **Паттерны согласованности**:
-	- [[Еventual consistency|Eventual Consistency]] + [[Идемпотентность|Idempotence]]: Для систем, допускающих временную рассогласованность.
-	- [[Transactional Outbox|Outbox Pattern]]: Для передачи данных между системами с гарантией доставки.
-
-***
-## Мета информация
-**Область**:: 
-**Родитель**:: 
-**Источник**:: 
-**Создана**:: [[2025-01-15]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
- [[Согласованность транзакции БД (Сonsistency)]]
- [[Еventual consistency]]
-<!-- SerializedQuery END -->
-
--- a/dev/fundamental/Deadlock.md
+++ b/dev/fundamental/Deadlock.md
@ -25,7 +25,7 @@ linked:
 - Выполнить повторно откатившуюся транзакцию

 **Что реально поможет:**
- Разделить потоки чтения и записи: [Command Query Responsibility Segregation](../../../../knowledge/dev/архитектура/паттерн/Command%20Query%20Responsibility%20Segregation.md)
+- Разделить потоки чтения и записи: [CQRS](CQRS.md)
 - Использовать материализованные view.
 - Изменить порядок блокировок ресурсов. Если в разных операциях блокируется определенный набор ресурсов, то блокироваться первым должен всегда один и тот же ресурс
 - Пересмотреть [Уровни изоляций транзакций БД](Уровни%20изоляций%20транзакций%20БД.md)
--- a/dev/fundamental/MESI.md
+++ b/dev/fundamental/MESI.md
@ -14,7 +14,7 @@ linked:
 - **S (Shared)** — данные разделены между несколькими ядрами, и их копии синхронизированы с памятью.
 - **I (Invalid)** — данные в кэше недействительны, потому что они были изменены другим ядром или сброшены.

-==Когда одно ядро изменяет данные в своем кэше, протокол MESI уведомляет другие ядра о том, что их копии этих данных больше не актуальны==. Это позволяет поддерживать [[../architecture/Согласованность данных|согласованность данных]] между ядрами и предотвращает возможные ошибки.
+==Когда одно ядро изменяет данные в своем кэше, протокол MESI уведомляет другие ядра о том, что их копии этих данных больше не актуальны==. Это позволяет поддерживать согласованность данных между ядрами и предотвращает возможные ошибки.

 ***
 ## Мета информация
--- a/dev/fundamental/Two-Phase
+++ b/dev/fundamental/Two-Phase
@ -1,64 +0,0 @@
---
-aliases:
-  - 2PC
-  - двухфазный-коммит
-  - двухфазный коммит
-tags:
-  - maturity/🌱
-date: 2025-01-13
---
-**Двухфазный коммит (Two-Phase Commit, 2PC)** — это протокол [[../architecture/Распределенная транзакция|распределённой транзакции]], который обеспечивает [[../architecture/Согласованность данных|согласованность данных]] между несколькими системами или узлами. Он используется для выполнения атомарных операций в распределённых системах, таких как базы данных и брокеры сообщений.
-
-**Преимущества двухфазного коммита**
- **Гарантия согласованности**. Все участники либо фиксируют изменения, либо откатываются к исходному состоянию.
- [[Атомарная операция|Атомарность операций]]. Транзакция выполняется полностью или не выполняется вообще.
-
-**Недостатки двухфазного коммита**
- **Производительность**.
-	- Протокол увеличивает задержки из-за необходимости согласования между участниками.
-	- Блокировка ресурсов (например, записей в базе данных) может привести к снижению пропускной способности системы.
- **Риск блокировок (Blocking)**. Если координатор выходит из строя, участники могут остаться в подвешенном состоянии, ожидая дальнейших команд.
- **Сложность реализации**. Настройка двухфазного коммита в распределённых системах требует глубокого понимания протокола и особенностей инфраструктуры.
- **Проблемы масштабирования**. Протокол плохо работает в системах с большим количеством участников из-за увеличения числа сообщений и времени согласования.
-
-Протокол состоит из двух этапов:
- **Фаза подготовки (Prepare Phase)**:
-	- Координатор транзакции отправляет запрос всем участникам (например, базам данных или брокерам сообщений) с просьбой подготовиться к выполнению операции.
-	- Участники проверяют возможность выполнения операции и сообщают координатору о своём статусе:
-		- **“Готов” (Vote Yes)**, если операция может быть выполнена.
-		- **“Не готов” (Vote No)**, если операция невозможна. Если хотя бы один участник возвращает “Не готов”, координатор инициирует откат транзакции.
- **Фаза фиксации (Commit Phase)**:
-	- Если все участники подтвердили готовность, координатор отправляет команду зафиксировать изменения (**Commit**).
-	- Участники фиксируют изменения и подтверждают выполнение операции.
-	- Если хотя бы один участник не может выполнить фиксацию, координатор отправляет команду отката (**Rollback**) всем участникам.
-
-**Двухфазный коммит применим, если:**
- Критически важно обеспечить [[../architecture/Согласованность данных|согласованность данных]].
- Количество участников в транзакции относительно небольшое.
- Высокая задержка или снижение производительности являются допустимыми.
-
-**Применение двухфазного коммита**.
- **Банковские транзакции**. Обеспечение согласованности при переводе средств между счетами.
- **Обновление нескольких баз данных**. Когда данные в разных базах должны быть изменены синхронно.
- **Интеграция с брокерами сообщений**. Обеспечение атомарности при отправке сообщений и обновлении базы данных.
-
-Однако, в большинстве современных распределённых систем предпочитают альтернативные подходы из-за их большей гибкости и масштабируемости.
-
-**Альтернативы двухфазному коммиту**
- [[../architecture/Идемпотентность|Идемпотентные операции]]. Вместо сложных транзакций системы обрабатывают повторы операций без изменений состояния.
- [[../architecture/Transactional Outbox|Outbox-паттерн]]. Использование промежуточного хранилища для согласования операций.
- [[../architecture/Event Sourcing|Event Sourcing]]. Применение событийной модели, где изменения состояния записываются как события, а не как транзакции.
- [[../../../../_inbox/Basically Available Soft state Eventual consistency|BASE]] вместо [[../database/Свойства транзакций БД|ACID]]. Принятие модели [[../../../../_inbox/Basically Available Soft state Eventual consistency|BASE]], которая допускает временную рассогласованность ради повышения производительности.
-***
-## Мета информация
-**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
-**Родитель**:: 
-**Источник**:: 
-**Создана**:: [[2025-01-13]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/dev/fundamental/Two-Phase
+++ b/dev/fundamental/Two-Phase
@ -1,50 +0,0 @@
---
-aliases:
-  - 2-phase lock
-  - 2PL
-tags:
-  - maturity/🌱
-date:
-  - - 2024-06-20
---
-Протокол **Two-Phase Locking (2PL)** управляет доступом к данным в базе данных, обеспечивая их корректность и изоляцию между транзакциями. 2PL работает по следующему алгоритму:
-
- **Фаза установки блокировок**: Транзакция может запрашивать блокировки для данных, которые она намерена использовать (чтение или запись).
- **Фаза снятия блокировок**: После начала снятия блокировок транзакция не может запрашивать новые блокировки.
-
-Эти две фазы предотвращают конфликты и обеспечивают согласованное выполнение операций.
-
-**Изменение данных (операция записи)**
- Запрашивается **блокировка на запись** (exclusive lock).
- Ожидается снятие всех блокировок, установленных до этой транзакции.
- Данные изменяются.
- Блокировка снимается.
-
-**Чтение данных**
- Запрашивается **блокировка на чтение** (shared lock).
- Ожидается снятие всех блокировок на запись, установленных до этой транзакции.
- Данные считываются.
- Блокировка снимается.
-
-**Важные особенности**
- **Блокировка на запись**. Она запрещает одновременно читать или изменять данные другим транзакциям.
- **Изоляция транзакций**. Согласно теореме 2PL, если все транзакции следуют этому протоколу, они будут изолированы друг от друга. Это значит, что каждая транзакция видит данные в состоянии, согласованном относительно её выполнения.
-
-**Преимущества 2PL**
- **Сериализуемость транзакций**. Обеспечивает корректность выполнения операций.
- **Гарантированная изоляция**. Исключаются конфликты между транзакциями.
-
-**Недостатки 2PL**
- **Ожидание блокировок**. Транзакция может быть вынуждена ждать, пока другие транзакции освободят ресурсы.
- Возможность [[deadlock]]. Две или более транзакции могут заблокировать друг друга, ожидая освобождения ресурсов.
-***
-## Мета информация
-**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
-**Родитель**:: [[Блокировка]]
-**Источник**:: 
-**Автор**:: 
-**Создана**:: [[2024-06-20]]
-### Дополнительные материалы
- [Two-phase locking - Wikipedia](https://en.wikipedia.org/wiki/Two-phase_locking)
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
--- a/dev/fundamental/Атомарная
+++ b/dev/fundamental/Атомарная
@ -1,10 +1,11 @@
 ---
-aliases:
-  - атомарность операции
-  - атомарность операций
+aliases: 
 tags:
  - maturity/🌱
 date: 2024-10-12
+zero-link: 
+parents: 
+linked:
 ---
 Операция атомарная, если невозможно наблюдать частичный результат ее выполнения. Любой наблюдатель видит либо состояние системы до атомарной операции, либо после

@ -12,10 +13,6 @@ date: 2024-10-12
 - Запись в поле типа boolean, byte, short, char, int, Object всегда атомарна
 - Запись в поле типа long/double: атомарна запись старших и младших 32 бит
 - Запись в поле типа long/double, объявленное volatile, атомарна
-
-**Подходы:**
- [[Two-Phase Commit|Two-Phase Commit]]
- [[../../../../_inbox/Transactional Inbox|Transactional Inbox]]
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
--- a/dev/fundamental/Блокировка.md
+++ b/dev/fundamental/Блокировка.md
@ -52,5 +52,5 @@ linked:
 ### Дочерние заметки
 <!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
 <!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
- [[Two-Phase Locking]]
+- [[Two Phase Lock]]
 <!-- SerializedQuery END -->
--- a/dev/network/Domain
+++ b/dev/network/Domain
@ -1,74 +0,0 @@
---
-aliases:
-  - DNS
-tags:
-  - maturity/🌱
-date:
-  - - 2024-01-13
---
-## Тезисы
- **DNS (Domain Name System)** — это система, которая преобразует доменные имена в IP-адреса и наоборот.
- DNS — это распределенная база данных, состоящая из множества серверов, которые хранят и предоставляют информацию о доменах.
- Основные компоненты DNS: клиент (resolving), серверы (root, TLD, authoritative), зоны и записи (A, AAAA, CNAME и другие).
- Процесс DNS-запроса включает несколько этапов, начиная от локального кэша до root-серверов и серверов имен.
-***
-**DNS (Domain Name System)** — это [[../architecture/Распределённая система|распределенная система]], которая позволяет пользователям использовать удобные доменные имена (например, `example.com`) вместо сложных для запоминания [[../../../../knowledge/dev/network/Internet Protocol v4|IP]]-адресов (например, `192.0.2.1`).
-
-По умолчанию DNS сервер работает на 53 порту.
-
-**Компоненты DNS**
- **DNS-клиенты (Resolvers)**
-    - Это программы или устройства, которые инициализируют DNS-запрос для преобразования доменного имени в IP-адрес.
-    - Пример: ваш браузер или операционная система.
- **DNS-серверы**:
-	- **Root-серверы**:
-		- Основной уровень в иерархии DNS.
-		- Направляют запросы к серверам TLD (Top-Level Domain).
-		- Существует 13 логических групп root-серверов (например, `a.root-servers.net`).
-	- **TLD-серверы**: Обрабатывают запросы для доменов верхнего уровня (например, `.com`, `.org`, `.ru`).
-	- **Authoritative Name Servers**: Хранят окончательную информацию о домене, включая IP-адреса, записи MX и другие.
- **DNS-зоны**:
-	- Фрагменты пространства имен, управляемые конкретным сервером.
-	- Пример: зона для `example.com` может включать записи для `www.example.com` и `mail.example.com`.
- **DNS-записи**:
-	- **A**: IPv4-адрес.
-	- **AAAA**: IPv6-адрес.
-	- **CNAME**: каноническое имя (псевдоним для другого домена).
-	- **MX**: почтовые серверы для домена.
-	- **TXT**: текстовые данные, используемые для SPF, DKIM, подтверждения владения.
-	- **NS**: серверы, обслуживающие зону.
-	- **PTR**: обратное преобразование IP в доменное имя.
-
-**Как работает DNS?**
-1. **Пользователь вводит доменное имя в браузере.**
-2. **Клиент (resolver)** проверяет локальный кэш. Если запись найдена, используется она.
-3. Если записи нет, запрос отправляется на root-сервер.
-4. Root-сервер перенаправляет запрос на сервер TLD (например, `.com`).
-5. TLD-сервер перенаправляет запрос на authoritative сервер для конкретного домена.
-6. Authoritative сервер возвращает нужную запись (например, IP-адрес).
-7. Клиент получает IP-адрес и устанавливает соединение с сервером по этому адресу.
-
-**Проблемы и угрозы DNS**
- **DNS Spoofing (подмена)**: Атака, при которой злоумышленники подменяют ответ DNS-сервера, перенаправляя пользователей на вредоносные сайты.
- **DDoS-атаки на DNS**: Направлены на перегрузку серверов, чтобы сделать их недоступными.
- **Кэш-поизонинг**: Внедрение ложной информации в кэш DNS.
- **Проблемы с конфиденциальностью**: DNS-запросы могут быть видны третьим сторонам, что создает риски слежки.
-
-**Современные улучшения DNS**
- **DNSSEC (DNS Security Extensions)**: Добавляет цифровую подпись для проверки подлинности записей.
- **DoH (DNS over HTTPS)** и **DoT (DNS over TLS)**: Шифруют DNS-запросы, повышая конфиденциальность и защищенность.
- **Anycast**: Используется для распределения запросов на ближайший DNS-сервер, улучшая производительность и устойчивость.
-
-## Заметки
- По умолчанию работает по протоколу [UDP](UDP.md), переходит на [TCP](TCP.md) если размер ответа больше 500 байт.
-***
-## Мета информация
-**Область**:: [[../../meta/zero/00 Сети|00 Сети]]
-**Родитель**:: 
-**Источник**:: 
-**Автор**:: 
-**Создана**:: [[2024-01-13]]
-### Дополнительные материалы
- 
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
--- a/dev/other/Race
+++ b/dev/other/Race
@ -8,6 +8,9 @@ tags:
  - maturity/🌱
 date:
  - - 2024-06-19
+zero-link: 
+parents: 
+linked:
 ---
 Состояние гонки возникает, когда два или более потока одновременно пытаются получить доступ к одному и тому же ресурсу (например, переменной), причём хотя бы один поток изменяет его значение. В таких случаях порядок выполнения потоков не гарантирован, что приводит к непредсказуемому поведению программы. Например, один поток может записывать данные, в то время как другой — читать, что вызывает некорректные результаты.

--- a/health/disease/Синдром
+++ b/health/disease/Синдром
@ -15,7 +15,7 @@ linked:
 **Почему возникает?**
 Иногда из-за дефицита железа, болезней почек, или ревматоидного артрита. Достаточно вылечить их - неприятные ощущения уйдут. Но бывает и так, что СБН начинается сам по себе. Тогда его лечат лекарствами, влияющими на дофаминовые рецепторы в мозге. 

-Каждый раз врач подбирает конкретное средства и дозировку индивидуально. Также показаны специальные упражнения, [[../../awareness/Медитация|медитация]], [[../../../../knowledge/mindfulness/Йога|йога]], и техники расслабления.
+Каждый раз врач подбирает конкретное средства и дозировку индивидуально. Также показаны специальные упражнения, [[../../../../knowledge/mindfulness/Медитация|медитация]], [[../../../../knowledge/mindfulness/Йога|йога]], и техники расслабления.
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Здоровье|00 Здоровье]]
--- a/health/human/Строение
+++ b/health/human/Строение
--- a/health/Коленный
+++ b/health/Коленный
@ -1,28 +0,0 @@
---
-aliases: 
-tags:
-  - maturity/🌱
-date: 2024-12-01
---
-**Коленный стул.** У этого стула нет спинки, но есть упор для коленей — нагрузка смещается с таза на колени и голени. Сидеть на таком стуле согнувшись неудобно. Поэтому приходится силой собственных мышц выравнивать спину и удерживать ее в вертикальном положении. То есть мышцы спины тренируются, даже когда человек сидит.
-
-![[../../../meta/files/Снимок экрана 2024-12-01 в 13.30.55.png]]
-
-В отличие от обычных стульев, коленные можно регулировать по высоте, углу наклона сиденья и расстоянию между сиденьем и подставкой для коленей. Вам подойдут модели, при сидении на которых ваши руки удобно лежат на столе и не затекают.
-
-Рекомендации:
- Выбирайте варианты с металлическим каркасом: они прослужат дольше. 
- Обратите внимание на коленные стулья со спинкой.
-***
-## Мета информация
-**Область**:: 
-**Родитель**:: 
-**Источник**:: 
-**Создана**:: [[2024-12-01]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/health/Кресло
+++ b/health/Кресло
@ -1,46 +0,0 @@
---
-aliases: 
-tags:
-  - maturity/🌱
-date: 2024-12-01
---
-Удобное кресло должно подходить к вашему росту. Поэтому в идеале в нем должны регулироваться все элементы:
-1. Высота сиденья. Стопы целиком стоят на полу, а ноги сгибаются под углом 90°.
-2. Глубина. Бедра полностью лежат на сиденье, ничто не мешает сгибать колени, а спина касается спинки кресла.
-3. Высота спинки. Изгибы спинки повторяют изгибы вашего позвоночника. В таком случае поясница и шея касаются кресла, опираясь на него.
-4. Угол наклона спинки. Настраивайте так, как удобно именно вам.
-
-**Альтернативы креслу:**
- [[Коленный стул|Коленный стул]]
- [[Стул седло]]
- [[Фитбол|Фитбол]]
-
-В кресле есть два элемента, которые настраивать не обязательно, к тому же с возможностью такой регулировки кресло будет стоить дороже — зато спина получит еще больше поддержки.
- **Высота и ширина подлокотников.** Когда руки лежат на них, следите за тем, чтобы плечи не поднимались. Если подлокотники мешают придвинуть кресло на комфортное расстояние к столу, от них стоит отказаться.
- **Подголовник.** Он поддерживает шею в месте изгиба и в идеале должен регулироваться по высоте, чтобы можно было настроить его под свой рост.
-
-В идеале все это учитывать при покупке, но если покупать новое кресло не хочется, то можно попробовать улучшить старое:
- **Меняем высоту кресла.** Если стопы не стоят на полу или, наоборот, слишком в него упираются, а рукам неудобно на столе, используйте дополнительные предметы. Если кресло слишком высокое, купите подставку для ног. Если слишком низкое — приобретите специальную подушку.
- **Делаем спинку удобной.** Для кресел с неудобными спинками есть специальные подушки, которые поддерживают спину в правильном положении.
-
-**Рекомендации:**
- Если вы решили купить новое кресло, выбирайте его прямо в магазине.
-
-
-***
-## Мета информация
-**Область**:: [[../meta/zero/00 Здоровье|00 Здоровье]]
-**Родитель**:: [[Рабочее место для работы сидя]]
-**Источник**:: 
-**Создана**:: [[2024-12-01]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
- [[Стул седло]]
- [[Фитбол]]
-<!-- SerializedQuery END -->
-
--- a/health/Работа
+++ b/health/Работа
@ -1,35 +0,0 @@
---
-aliases:
-  - работая стоя
-tags:
-  - maturity/🌱
-date: 2024-12-01
---
-
-Такой вариант подойдет растущим детям и для работы за одним столом разных людей.
-
-Это положение всегда должно быть только одним из вариантов. Если работать так слишком долго, стопы перегрузятся, могут появиться отеки. А у человека со сколиозом или перенапряженными мышцами усугубятся проблемы со спиной.
-
-![[../meta/files/images/Pasted image 20241201130758.png]]
-
-В идеале нужно оборудовать дома места для работы сидя и стоя и использовать каждое для конкретных задач или просто для смены положения в течение дня. Например, стоя можно проводить созвоны или читать текст с экрана. А сидя — печатать отчеты.
-
-При работе стоя важно, чтобы монитор был на уровне глаз. Если вы работаете так вне дома, подберите удобную обувь: без каблука и с широким носком, чтобы свободно двигать пальцами и опираться на пятку, большой палец и мизинец. И главное — ==как только почувствуете от тела сигнал «есть усталость, пора сесть», смените положение.==
-
-
-
-
-
-***
-## Мета информация
-**Область**:: [[../meta/zero/00 Здоровье|00 Здоровье]]
-**Родитель**:: [[Рабочее место для работы сидя]]
-**Источник**:: 
-**Создана**:: [[2024-12-01]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/health/Рабочее
+++ b/health/Рабочее
@ -1,54 +0,0 @@
---
-aliases: 
-tags:
-  - maturity/🌱
-date: 2024-12-01
---
-Идеальное рабочее место должно быть удобным ровно настолько, чтобы не вставая провести за ним 30—50 минут, — и неудобным настолько, чтобы через 30—50 минут захотелось встать и размяться.
-
-1. Обе стопы стоят на полу
-2. Колени согнуты под углом 90°
-3. Поясница в легком прогибе
-4. Руки свободно лежат на столе и подлокотниках, не упираясь в них
-5. Плечи расправлены и свободно опущены
-6. Монитор на уровне глаз
-7. Вы можете легко менять положение и вставать без препятствий
-
-![[../../../meta/files/Урок 2 Рабочее место.png]]
-
-==При работе за компьютером или ноутбуком важно, чтобы монитор был на уровне глаз, — это единственный критерий правильного расположения техники.== Когда монитор слишком низко, шея постоянно находится в согнутом положении, а голова наклонена — это увеличивает нагрузку на шейный отдел позвоночника и перенапрягает мышцы.
-
-Клавиатура и мышь должны располагаться так, чтобы предплечья комфортно лежали на подлокотниках или столешнице, а локти сгибались под углом 90°. В случае со стационарным компьютером сделать это просто: достаточно подобрать стол и кресло.
-
-Если вы работаете с ноутбуком, поставьте его на подставку. И подключите дополнительную клавиатуру, чтобы она и мышь находились на столешнице. Поначалу выглядит неудобно, но к этому быстро привыкаешь.
-
-Для разминки спины стоит двигаться хотя бы по 5—10 минут после 30—50 минут работы сидя. Также не стоит забывать, что работать за компьютером безопасно не больше 6⁠—⁠8 часов в сутки. Если работать больше — [повышается риск](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5574844/) возникновения [[../../../knowledge/health/болезни/Депрессия|депрессии]]. Поэтому наша задача — [[../../../knowledge/productivity/Формирование новых привычек|привыкнуть]] двигаться 5—15 минут в течение часа, а когда именно — решать вам. Это идеально подходит под [[../productivity/Метод "Помидора"|Метод "Помидора"]].
-
-**Рекомендации:**
- Проводите созвоны [[Работа стоя|работая стоя]] или на прогулке;
- Если вы часто работаете в разных местах на ноутбуке, носите с собой портативную подставку. А в идеале и дополнительную клавиатуру с мышкой.
-
- [[Кресло для работы]]
- [[Стол для работы|Стол для работы]]
-	- [[Работа стоя]]
-
-***
-## Мета информация
-**Область**:: [[../meta/zero/00 Здоровье|00 Здоровье]]
-**Родитель**:: 
-**Источник**:: 
-**Создана**:: [[2024-12-01]]
-**Автор**:: 
-### Дополнительные материалы
- [Fetching Title#tntq](https://journal.tinkoff.ru/pro/osanku/)
- [[../Мое рабочее место|Мое рабочее место]]
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
- [[Кресло для работы]]
- [[Работа стоя]]
- [[Стол для работы]]
- [[Мое рабочее место]]
-<!-- SerializedQuery END -->
-
--- a/health/Разминка
+++ b/health/Разминка
@ -1,32 +0,0 @@
---
-aliases: 
-tags:
-  - maturity/🌱
-date: 2024-12-01
---
-Помните о главном принципе: двигаться хотя бы по 5—10 минут после 30—50 минут в одном положении Лучшая разминка — смена положения. Если вы лежали, встаньте или сядьте. Сидели — встаньте или лягте. Но если вы не можете или не хотите менять положение, облегчить ощущения в спине поможет небольшая разминка. Главное — помнить об общих принципах.
-
-**Принять нейтральное положение позвоночника** — то, в котором он сохраняет свои естественные изгибы. Это наиболее безопасное положение для суставов позвоночника и межпозвонковых дисков.
-
-При нейтральном положении изгибы должны сохраняться, но не становиться чрезмерными:
-
-![[../../../meta/files/Pasted image 20241201142918.png]]
-
-![Site Unreachable](https://youtu.be/AbHwhP1nz9g)
-
-![РАЗМИНКА СИДЯ НА СТУЛЕ для здоровья спины и шеи. 7 мин. - YouTube](https://youtu.be/wV_E5GXJbhw)
-
-![Разминка для офиса. Удобные движения в неудобной одежде - YouTube](https://youtu.be/Db2qf76bmsU)
-***
-## Мета информация
-**Область**:: 
-**Родитель**:: 
-**Источник**:: 
-**Создана**:: [[2024-12-01]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/здоровья.md
+++ b/здоровья.md
@ -1,23 +0,0 @@
---
-aliases: 
-tags:
-  - maturity/🌱
-date: 2024-12-01
---
- [[Сидячий образ жизни]]
-***
-## Мета информация
-**Область**:: [[../meta/zero/00 Здоровье|00 Здоровье]]
-**Родитель**:: 
-**Источник**:: 
-**Создана**:: [[2024-12-01]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
- [[Сидячий образ жизни]]
-<!-- SerializedQuery END -->
-
--- a/health/Сидячий
+++ b/health/Сидячий
@ -1,42 +0,0 @@
---
-aliases: 
-tags:
-  - maturity/🌱
-date: 2024-12-01
---
-Мы сидим в офисе и дома, в автобусе и метро, в ресторане и кино — в общем, везде, где можно присесть. И обычно за этим не следим. В итоге можем оказаться в ситуации, когда спина болит, шея напрягается, в пояснице тянет.
-
-Последствия сидячего образа жизни можно свести к минимуму без огромных усилий.
-
-> [!TIP] [[../../../_inbox/Аксиома|Аксиома]]
-> Можно сидеть как угодно, если менять положение и регулярно двигаться.
-
-Сидячий образ жизни влияет на:
- Дыхание. Грудная клетка сжата - не хватает кислорода.
- Выносливость.
- Пищеварение. Органы пещеварения сжаты сжаты - сложнее переваривать еду.
- Износ суставов. Выше риск развития артроза и артрита.
- Нагрузку на позвоночник. Шея наклонена вперед - сильная нагрузка на позвоночник.
- [[../../../knowledge/human/Эмоции|Эмоции]]. Сутулость связана со стрессом и печалью.
-## Мифы
- **Когда мы сидим, спина устает меньше, чем в положении стоя.** [В положении сидя нагрузка на позвоночник выше](https://journals.lww.com/spinejournal/abstract/1999/04150/new_in_vivo_measurements_of_pressures_in_the.5.aspx), чем в положении стоя. А если наклониться вперед, работая за компьютером, нагрузка возрастет еще больше.
- **Правильное положение сидя — это когда спина прямая.** Ровная осанка снижает нагрузку на позвоночник, но мышцы сильно напрягаются и устают, когда фиксируют и удерживают это положение. Поэтому мы все равно перенапряжем мышцы, если будем долго сидеть с прямой спиной. Чтобы этого не случилось, [стоит время от времени менять положение.](https://www.tandfonline.com/doi/abs/10.1080/00140139.2017.1402960)
- **В кресле со спинкой спина не устает.** Кресло с эргономичной спинкой помогает принять правильное положение и поддерживает осанку. В итоге вы сможете сидеть в ровном положении с минимальным вредом для здоровья чуть дольше. Но мышцы в статичном положении все равно устают и нуждаются в движении. Поэтому все равно надо регулярно менять положение, вставать с кресла и двигаться. На самом деле эффективный способ разгрузить спину — принять положение лежа.
- **Корсеты улучшают осанку, если носить их полдня.** [Корсеты действительно фиксируют тело в правильном положении](https://www.cochranelibrary.com/cdsr/doi/10.1002/14651858.CD001823.pub3/full). Но мозг и нервная система не используются для этого и не привыкают поддерживать осанку самостоятельно. Эффективнее самому выравнивать осанку и укреплять мышцы упражнениями. А корсеты стоит носить ограниченное время и только по медицинским показаниям, например из-за высокого риска травмы или когда она уже случилась.
- **Сидеть нога на ногу — вредно для спины.** Для спины вредно долго находиться в одной позе без движения. Если периодически вставать, разминаться, менять положение сидя — можно спокойно сидеть нога за ногу.
-
-## Влияние на здоровье
-
-***
-## Мета информация
-**Область**:: [[../meta/zero/00 Здоровье|00 Здоровье]]
-**Родитель**:: [[Риски для здоровья]]
-**Источник**:: 
-**Создана**:: [[2024-12-01]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/работы.md
+++ b/работы.md
@ -1,37 +0,0 @@
---
-aliases: 
-tags:
-  - maturity/🌱
-date: 2024-12-01
---
-Можно упростить себе задачу и купить стол с подъемным механихмом, тогда можно не подбирать по росту. А 
-
-| Рост       | Высота стола | Высота сиденья |     |
-| ---------- | ------------ | -------------- | --- |
-| 93—116 см  | 46 см        | 26 см          |     |
-| 108—121 см | 53 см        | 31 см          |     |
-| 119—142 см | 59 см        | 35 см          |     |
-| 133—159 см | 64 см        | 38 см          |     |
-| 145—177 см | 71 см        | 43 см          |     |
-| 159—188 см | 76 см        | 46 см          |     |
-| 174—207 см | 82 см        | 51 см          |     |
-
-Опору рукам должны давать либо подлокотники, либо столешница. Подлокотники должны быть чуть ниже стола, чтобы кресло можно было легко под него задвинуть.
-
-Поэтому ==единственный критерий при выборе стола — положение предплечий.== Все остальное — размер поверхности, внешний вид — не имеет большого значения.
-
-Чтобы подобрать удобный стол, можно сесть в кресло, которое вы собираетесь использовать для работы, согнуть руки в локтях и измерить расстояние от предплечья до пола. Так вы поймете, какая высота столешницы вам нужна, и сможете выбрать подходящий стол дома или купить в интернет-магазине.
-
-***
-## Мета информация
-**Область**:: [[../meta/zero/00 Здоровье|00 Здоровье]]
-**Родитель**:: [[Рабочее место для работы сидя|Рабочее место для работы сидя]]
-**Источник**:: 
-**Создана**:: [[2024-12-01]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/health/Стул
+++ b/health/Стул
@ -1,27 +0,0 @@
---
-aliases: 
-tags:
-  - maturity/🌱
-date: 2024-12-01
---
-**Стул-седло.** Спинка обычных стульев и угол сгибания тазобедренных суставов заставляют подворачивать таз вперед. А форма стула-седла позволяет легко отклонять таз назад. В таком положении грудной отдел, плечи и шея без особых усилий занимают естественное положение, мышцы спины тренируются.
-
-![[../meta/files/images/Pasted image 20241201133737.png]]
-
-Стулья-седла могут регулироваться по-разному. При выборе обращайте внимание на несколько параметров:
-1. Регулировка высоты позволяет держать стопы целиком на полу. Угол в коленях будет больше 90°, но за счет конструкции сиденья это не вредит.
-2. Регулировка наклона позволяет сдвигать корпус немного вперед или назад.
-3. Регулировка ширины сиденья позволяет обеспечить максимально комфортную опору для таза и бедер.
-***
-## Мета информация
-**Область**:: [[../meta/zero/00 Здоровье|00 Здоровье]]
-**Родитель**:: [[Кресло для работы]]
-**Источник**:: 
-**Создана**:: [[2024-12-01]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/health/Фитбол.md
+++ b/health/Фитбол.md
@ -1,32 +0,0 @@
---
-aliases: 
-tags:
-  - maturity/🌱
-date: 2024-12-01
---
-Фитбол это гимнастический мяч, на котором можно сидеть. Нагрузку на спину уменьшает не только нейтральное положение позвоночника, которое легко поддерживать на фитболе, но и [различные движения, которые можно делать не вставая с мяча.](https://aconit.ru/articles/2182/)
-
-Как выбрать фитбол по своему росту
-
-| Рост       | Диаметр мяча |
-| ---------- | ------------ |
-| 120 см     | 40 см        |
-| 120—154 см | 45 см        |
-| 155—170 см | 55 см        |
-| 170—185 см | 65 см        |
-| 185—190 см | 75 см        |
-Также важно учитывать максимальный вес, который выдержит фитбол.
-
-***
-## Мета информация
-**Область**:: [[../meta/zero/00 Здоровье|00 Здоровье]]
-**Родитель**:: [[Кресло для работы|Кресло для работы]]
-**Источник**:: 
-**Создана**:: [[2024-12-01]]
-**Автор**:: 
-### Дополнительные материалы
- 
-
-### Дочерние заметки
-<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
-
--- a/meta/date/daily/2024-10-19.md
+++ b/meta/date/daily/2024-10-19.md
@ -1,11 +1,8 @@
 ## Заметки созданные в этот день
 <!-- QueryToSerialize: LIST WHERE "garden/ru" and (contains(date, this.file.link) or contains(Создана, this.file.link)) -->
 <!-- SerializedQuery: LIST WHERE "garden/ru" and (contains(date, this.file.link) or contains(Создана, this.file.link)) -->
- [[Голосарий Java]]
- [[Куча]]
- [[Передача значений в метод в Java]]
- [[Примитивный тип]]
- [[Ссылочный тип]]
+- [[2024-10-19 1729318046]]
 - [[Семантический разрыв]]
+- [[Голосарий Java]]
 <!-- SerializedQuery END -->

--- a/meta/files/compression.log
+++ b/meta/files/compression.log
@ -0,0 +1,8 @@
+2024-11-17 19:28:15 Сжат PNG файл: ./images/Pasted image 20240528082025.png на 9.32% (270525 байт -> 245303 байт)
+2024-11-17 19:28:16 Сжат PNG файл: ./images/Pasted image 20240911091521.png на 59.39% (102395 байт -> 41582 байт)
+2024-11-17 19:28:16 Сжат PNG файл: ./images/Pasted image 20240911091002.png на 62.61% (110375 байт -> 41264 байт)
+2024-11-17 19:28:33 Сжат PNG файл: ./images/Pasted image 20240909083940.png на 17.54% (637823 байт -> 525968 байт)
+2024-11-17 19:28:43 Сжат PNG файл: ./images/Pasted image 20240401205236.png на 10.20% (792209 байт -> 711424 байт)
+2024-11-17 19:28:49 Сжат PNG файл: ./images/Pasted image 20241103220807.png на 30.29% (1179914 байт -> 822467 байт)
+2024-11-17 19:29:05 Сжат PNG файл: ./images/Pasted image 20240912082100.png на 0.75% (2371400 байт -> 2353730 байт)
+2024-11-17 19:29:10 Сжат PNG файл: ./images/Pasted image 20240911091644.png на 16.51% (347231 байт -> 289913 байт)
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+fe5211690440712aa0aee37e87a80031
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+80a8abfcfb032a78c154e06ea0e00d0e
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+b314a26e5b759b8a48a1abcfe321cc45
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+68c3bf8ad6913417522e10a5a50770d5
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+79ab0edb2a1beebe635c8f184012dd4b
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+54b981b57be652f0497aa45f1cd2caa8
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+9089682c4ce30d092841cd56b83e45dc
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+cdff89f89c87657e8156d33cf04d1b0e
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+09cee464e8cde107fb749fc52c85ea5e
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+40a9f3f2a42b3c4d0b32ef1005c53615
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+3c76630cb2970d95ef5071465c1df3cf
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+843fae8f7c28b46b78993647eb216136
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+013539aafe2f090b059b440e61bc8a92
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+5112f9539443c082b5f652d352fd89dc
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+c63efc54950293ca8defff62eb7d404a
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+f2e403f5e91c67b0f855fb16a6edbc3f
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+4687fcfec567331eaf6a3bd07939d814
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+43d29184b1f569e40bec5a89bbc6cb64
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+3c3b02f19d5dff3c5b310e8a5d799e97
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
@ -0,0 +1 @@
+dd0abfccae87d2b67bfee0580de69a6d
--- a/meta/files/images/comp/Pasted
+++ b/meta/files/images/comp/Pasted
--- a/Show More
+++ b/Show More